Your API microservices are growing and growing ... how can you best manage them?
Continuing our journey with 'Fundamentals of API Security', a four part video series.
Time to continue our journey on 'Fundamentals of API Security' and take a look at what you need to look out for when it comes to managing your API microservices?
In previous blogs and videos, I highlighted how hackers will try to disrupt your business by gaining Intel on your API microservices and subsequently move on to manipulate the data behind your APIs. Of course, while you building more and more API microservices, newer versions of existing APIs and managing the infrastructure your APIs are running on, it becomes harder to properly manage your APIs. Time to go over a few best practices and tips.
Security Misconfiguration
OWASP manages Security Misconfiguration as one of the ten API risks. While this is a 'catch-all', here are some tips:
Your API runs on specific infrastructure that brings its own set of technical configuration with it and requires careful consideration. For instance, most of the APIs are running on HTTP/HTTPS. Ensure that you are using HTTPS instead of the less secure HTTP. Similarly, there are many different HTTP Methods available, make sure you disable other HTTP Methods not allowed for your API endpoints.
With cloud computing and many DevOps/DevSecOps tooling in place, it is also important to protect this infrastructure properly.
- Are all the elements properly secured?
- Are you using basic username/password on your API servers?
- Have you patched them to the latest versions?
- Are you ensuring proper encryption between systems?
- If your APIs are returning specific assets like images or videos, are these assets properly protected from access?
Make sure you also set the right policies in your team when it comes to reviewing your infrastructure periodically, especially when it comes to patching and tracking zero-day vulnerabilities which can have a huge impact on your APIs for instance the recent log4j vulnerability found.
Improper Asset Management
You may have tons of microservices up and running, dozens if not hundreds of API endpoints ready to go. Your APIs might even be publicly accessible by anyone and you may have documentation available on the Internet for anyone to see. This is where Improper Asset Management comes into play.
It is critical that you version your APIs properly, so you can track changes over the course of the lifecycle of your API while also ensuring that you properly retire older versions in order to make sure you reduce the attack surface of your API.
It is not uncommon that older versions of an API are attacked because they are less secure, newer versions built in newer security mechanisms, yet the older unpatched version is just simply available. This could even be found inside your API documentation, where you still list the old version’s documentation.
Documentation in general is very important, having both an internally and also externally available documentation that explains your API, the versions, the endpoints/functions available, which HTTP methods they use, the properties that are part of the object and which can be changed where, is all critical information. Even error messages can be useful when it comes to API documentation.
Lower Level Environments
If you are running your API stack in parallel with other environments such as a Test, Staging and Production environment, make sure that your API stack adheres to the same version control and CI/CD pipeline to deploy changes.
- Are these lower environment API stack publicly available?
- Are they properly protected as well?
- Are they isolated sufficiently from your Production environments?
These are all important questions to think about. Think about using OpenAPI specification to add as much of this as possible in your API definition and documentation.
Insufficient Logging and Monitoring
Your API infrastructure can benefit greatly from adding monitoring and logging to ensure that you have proper visibility on what is happening with your APIs at any given time. Having the ability to track which API requests were made can be helpful in audit trails in case a breach happens. Of course, this comes with the challenge of ensuring that your logs are properly secured and cannot be accessed by those who don’t have access to them.
Tracking spikes in traffic, especially for potential attacks or high load can also make sure your auto-scaling policies kick in properly. API Availability is a critical component, as mentioned before, if your API is not available for anyone to use, especially at critical moments, this can have serious implications for your business.
Access logs to your API’s infrastructure is also critical. Who logged in to which system when? Who has access to your CI/CD pipelines? Who has access to your logs/monitoring systems? It is important to put this in place.
It might not be the most critical component of your API itself but having a secure infrastructure in place for your API to operate at peak capability is important to take into consideration, especially when your business is growing rapidly and more and more users are consuming your APIs.
Being able to track the ‘State of your APIs’ at any given time with proper monitoring and logging is a critical part in achieving proper API security.
In Closing
With that, I will end this blog here and soon will wrap up with a summary. For more information, please take a look at the fourth video in the 'Fundamentals of API Security' series.
I also encourage you to try out crAPI for yourself and study the OWASP API Security Top 10.
Thanks again for all your support on this series! Consider leaving feedback and if you have any questions or want to see other API related topics covered in the future, let me know. You can find me on social media under Mike Elissen
Join me next time as we close out the blog and video series for now but our journey to keep your API microservices secure will be ongoing as usual!