An application programming interfaces (API) is the connective tissue of scalable websites—indispensable for functioning in a digital world. But, as in the physical world, weaknesses in those connections can cause serious, sometimes existential, trouble.
One recent example is data leaks resulting from misconfiguration of Microsoft Power Apps portals to allow public access. According to UpGuard, “the types of data varied between portals, including personal information used for COVID-19 contact tracing, COVID-19 vaccination appointments, Social Security numbers for job applicants, employee IDs, and millions of names and email addresses.”
But the operators of those portals have lots of company; API misconfigurations and the attacks they attract are more common than you’d expect. Indeed, Salt Security reported earlier this year that of nearly 200 enterprise security officials they surveyed, 94% said their organisation had experienced an API security incident in 2020. The report also highlighted malicious API traffic had increased 348% over six months, and indication of how attackers are focusing their attention on data access.
And at the end of 2019, OWASP started a separate “OWASP API Security Top 10” covering API weaknesses. APIs represent a ready method to access data exposed by an organisation. Some APIs are intended for public use, while others are intended for use within an application. Regardless of their usage, an API is designed to provide direct access to data and as such should be explicitly tested to ensure it doesn’t return excess data or that authorisation bypasses are possible. In the BSIMM12, activity ST2.6 covers fuzz testing of APIs, but only 12% of organisations were found to be performing this activity.
John Tapp, senior consultant with the Synopsys Software Integrity Group, laid out some best practices for API monitoring and protection.
Inventory and documentation: A security cliché (and it’s a cliché because it’s true) is “you can’t protect what you don’t know you have.” And that is the problem with far too many APIs.
“It’s like an iceberg,” Tapp said, referring to the image of only 10% of the ice visible above the surface. “A lot of code may not be formally documented in a way either humans or machines can consume, so it may not get tested.”
To address this:
- Build an inventory of API-based application assets
- Prioritise them by risk level
- Find API endpoints for those assets
- Track automated deployments to maintain your API inventory
- Automate detection of issues with security tools and services
Identity and access management (IAM) is a standard security practice. But for APIs, it should focus on how users are authenticating to the API and how the API is authorising each user at different points. “Authentication is your ID at the security checkpoint in the airport, while authorisation is the boarding ticket at the gate,” Tapp said.
“There are all sorts of different ways to do that,” he added. “But you’ve got to track that user through the system. Each function within the app needs to be designed with an understanding of its responsibilities for authenticating or authorising the user.”
Data trust: Consider how your APIs validate the data they receive from the data consumer, and whether it is malformed. If so, how is it being fixed?
“Just like with web applications, APIs must conduct input validation,” Tapp said. “When you’re communicating with APIs, an attacker may try to modify the way you’re sending the data. The API needs to know what to do with malformed data. But the way validation is done might be a little different—not only the values of parameters need to be checked, but also the schema the data is communicated in.”
Cryptography: This should go without saying, but it is critically important to ensure data at rest and in transit are encrypted in a secure manner and when needed.
Also, JSON Web Tokens are frequently used for AuthN/AuthZ but are cryptographically signed, which needs to be validated by the API.
Configuration: If you are deploying your API in a cloud environment or with containers, make sure that those are configured securely so as not to weaken or even undo all the hard work put into securing the API.
Indeed, API misconfiguration is API7:2019 on the OWASP API Top 10. It can include unpatched systems, unprotected files and directories, unhardened images, missing, outdated, or misconfigured TLS, exposed storage or server management panels, missing CORS policy or security headers, error messages with stack traces, and unnecessary features enabled.
It is also almost certain you are using open source software—the 2021 Open Source Security and Risk Analysis Report by Synopsys documented that 98% of codebases contain open source components and that it made up an average of 75% of those codebases.
Focus on the security of those components by using a software composition analysis tool to help find known vulnerabilities and potential licensing conflicts.
Active monitoring/alerting: This requires several key areas of focus. They include:
- Examining the content: Perform application layer scanning to look for someone trying to use SQL injection. Be sure you have a clear understanding of how you are examining traffic coming into your API, and what you are doing with that traffic.
- Bot/attack detection: Ensure that you have controls in place or built into your APIs to protect against known attack techniques and heavily automated attacks conducted by bots.
- Data throttling: Determine how you will limit API usage and what you will do when usage has exceeded your limits.
- Logging: Build a tactical auditing procedure—You should be auditing logs and getting meaningful alerts that give you what you actually need.
- Tracing: The ability to trace any negative findings or activities back to their source—a development team or application—is particularly valuable. Without it, you are not setting yourself up for success.