When you expose API services to the public internet, you are responsible not only for their reliable operation, but also for their security. Sufficiently securing and protecting a public API is not just a business necessity – it’s a regulatory requirement. If your APIs are leaking secrets and sensitive PII information, you run the risk of facing lawsuits for failing to protect that information by properly securing them.
This may sound cliché, but the harsh truth is that many public APIs contain numerous vulnerabilities. Therefore, properly securing APIs so that the worst-case scenario doesn’t become a reality is a major challenge for development teams.
This article aims to give the reader a better understanding of what will work and what won’t work in the context of API security. We will walk you through the most essential considerations, taking into account the fact that there is no silver bullet for API security due to the ways in which APIs are built and deployed.
Let’s get started.
Reasons Why APIs Are Hard to Test and Secure
APIs come in all shapes and sizes. The most critical parts of an API are often the most susceptible to attacks on vulnerabilities like those listed in the OWASP API Security Top 10. For example, attackers might attempt to abuse paths for logged in users, exfiltrate sensitive data by fuzzy testing the endpoints, or force the site down using DDoS attacks. As the API surface increases, of course, so does the risk of exposure. Imagine having to protect APIs with hundreds of endpoints, each with its own conventions.
This could happen quite easily when there are multiple teams working on the same project and contributing to the same API. The API might not have a sole owner; instead, it might be exchanged between multiple stakeholders (such as project owners, developers, testers, operations, and network and security teams), with each group submitting their own piece to deliver new features to their customers.
Relying too heavily on some parts of the delivery pipeline to include sufficient security controls is equally problematic. For example, you shouldn’t rely on the development team to constantly provide the most secure software all the time. Developers do not habitually think like attackers. They will incorporate basic pragmatic reasoning and accept logical trade-offs when delivering sprint goals. However, they will miss important security considerations fairly often simply because they are generally unaware of use and abuse scenarios. Likewise, if you expect your WAFs to perpetually block all unwanted traffic and your static code analyzers to always pinpoint all security flaws in the code, then you will be in for a big surprise when attackers exploit unknown vulnerabilities or zero-day bugs.
Therefore, since APIs are hard to test and secure, you must be innovative in finding conventional tools, agile methodologies, and various approaches that work well together. Let’s explore some of them.
Tools and Approaches That Work Well Together – and Some That Don’t
Once you have established that you need to use flexible approaches to keep your APIs secure, you want to make sure that you are following the right guidance. There are lots of great guides and best practices for API security, but it’s important to differentiate the ones that make the most sense for your APIs from the ones that don’t.
Some of the approaches that work with API security are mainly focused on establishing in-depth defenses:
- Authenticate and authorize by default: When you are developing APIs, you should explicitly mark unauthenticated endpoints (and not the other way around). For example, you should protect all endpoints with strong authentication (2-factor) and assign a default role that cannot read or modify any data. That way, there is less risk of exposing new endpoints that do not have any sort of protections.
- Use API security scanners: Tools and services in this category include runtime protection, DAST (vulnerability scanning tools), static code analyzers, and security bots. These tools provide a nice layer of defense against baseline security issues.
- Use penetration testing: You can hire professionals who think like attackers and are able to perform sophisticated tampering. These professionals have access to unconventional tools and leverage techniques that help expose issues that security scanners won’t pick up by default.
On the other hand, some approaches might not work in the long run because they possess inherent risks. For example:
- Security through obscurity: This means that we try to secure part of the API by making it harder to use or to discover its endpoints or behavior. This is like an Easter egg hunt where you expose certain parts of the API only to clients that know where to look for them. Or you might make it harder for attackers to guess some of the API schemes by using special query parameters or headers. Although this approach might work for certain cases, it is not considered 100% secure. Cunning attackers might figure out a way to uncover those hidden parts of the API or infer how the API response works, which would give them the ability to retrieve sensitive information.
- Using JSON Web Tokens (JWTs) for storing sensitive data: JWTs offer a good balance between security and convenience when working with APIs – as long as you abide by the rules. If you store sensitive data in the JWT payload, for example, you are already compromising security since JWTs can be decoded easily. Always use industry-standard JWT libraries, strong JWT secrets, and short expiration tokens. In addition, always use HTTPS.
We mentioned before that APIs can be secured by automating the scanning of application code. Let’s explore that in more detail.
How to Effectively Scan APIs
Start with the source of truth, the source code. By scanning the source code, you get a complete view of what APIs are inside of a project. This also allows developers to easily and quickly fix any security issue that has been identified by this static analysis. Since APIs need to be human-readable, scanning the API Documentation as Swagger can also be key to identifying risk—checking key risks like access control, configurations, and best practices. This is an example of shift-left security, wherein DevOps teams ensure that security is built into application development rather than added on later.
Next, once those APIs are moved to an environment, it is easy to perform real E2E tests based on predefined rules against your real API. If the scanner finds any defects or suspicious red flags, it will report them to a dashboard for triaging. These scanners include many checks (like the OWASP API Security Top 10 and open CVEs) and can automatically create policies without intervention.
Even if you have a perfectly valid specification file, though, it doesn’t mean that the scanners will find all of the issues. It’s equally important that you are able to feed the scanner raw HTTP recorded sessions using either Fiddler or Burp so that it can verify unknown parts of the API.
Ways to Address the Continuous Development of APIs and Ever-Changing Contracts
At the end of the day, how can you address the continuous development of APIs and ever-changing contracts when you have to contend with multiple attack vectors in real time?
There are several options to consider:
- Scan early and often: Software is developed at the speed of light nowadays.The only way to keep up with the ever-changing contracts is scanning the API Documents and Source Code when they are changed by the development team.This can alert them immediately to critical vulnerabilities and risk. Allow the developer to learn better practices and secure the APIs well before they are live.
- Create clean environments for security testing: Sometimes you can’t slow down the release of new features in the name of security. It’s important that security teams create special environments where they can introduce novel security testing tools and scanners for advanced security testing. The primary idea is to conduct intelligent analytics, pinpoint hidden attack vectors, and expose vulnerabilities without affecting the production environment. Once a security issue has been found and mitigated in this special environment, the security team can patch the production systems using the current change request system.
- Adopt DevSecOps workflows: DevSecOps is about integrating your IT security team into the full lifecycle of your app. Put simply, this means that security teams follow short and frequent development cycles, integrate security tools and vulnerability scanners with minimal intervention, ensure that all operational technologies run with the optimal security configurations, and promote a security-first mindset across isolated teams. This can be accomplished by including automated security checks throughout the CI/CD process and creating service templates that are secure by default for the development teams to adopt.
Next Steps with API Security
We want to conclude this article by emphasizing the fact that there is no way your APIs can be 100% secure at all times. Instead, organizations should be constantly vigilant to scan their APIs for risks and vulnerabilities. As a security professional, it’s crucial that you stay informed about the status of the API security ecosystem. Reading security advisories like the ones from Checkmarx is a great way to acquire this knowledge. Their advisories discuss real public exposures while providing deep root cause analysis and explaining mitigation tactics. Feel free to sign up for more tutorials about API security and DevSecOps.
About the Author
Theo Despoudis is a Senior Software Engineer, a consultant and an experienced mentor. He has a keen interest in Open Source software Architectures, Cloud Computing, best practices and functional programming. He occasionally blogs on several publishing platforms and enjoys creating projects from inspiration. Follow him on Twitter @nerdokto.
..
..
To learn more about the many risks (including APIs) in modern application development, download this e-book today.
Or if you would like to learn more about Checkmarx approach to API security within the Checkmarx One™ Application Security Platform, this white paper explains it all.
