API Security

API is the acronym for application programming interface. It is a software intermediary that allows two applications to talk to each other. Commonly used by many companies, especially Fintech and eCommerce companies.

It is estimated that $40bn to $75 a year in cyber loss is related to APIs. APIs expose so much application functionality and there is a need to secure them.

Why is API security important?

• API attacks are different. The threats are different than what our web apps have seen.
• Apps are developed more quickly, in more agile ways and there is a lot of reliance on developers to secure the code and integrate security into the applications.
• Change in how applications are developed, deployed, and operated with things like cloud native strategies, use of UI for other functions other than presentation etc.
• Existing application security controls and testing have not caught up with the way APIs are built and used. API attacks targets logic flaws, gaps in authentication and authorizations within.
• Use of user interface (UIs) for security and no further controls at the backend.

I will share some relatable things on how to secure our APIs. Some of these, we may already be doing.

• Do not trust any third-party APIs. Zero trust here, your application should not assume that the data coming back from external providers is legitimate. Authenticate and authorize.
• Check for business logic vulnerabilities in the application along with your regular vulnerability scanning and pentesting. Logic flaws in an application get exposed via the API, allowing a threat actor to exploit it.
• Encrypted admin console access not just for browser-based UIs, but also for APIs.
• Expand your DEVSECOPS beyond your applications, systems and Software but also include bespoke and custom software incorporating APIs.
• Data Classification and protection. Understand how your sensitive and important data are handled by the application to determine how to protect it throughout its lifecycle.
• All relevant employees (developers, security teams) should be trained. Specifically, trainings on API related risks as well as best practices for avoiding API exposures and vulnerabilities.
• Web application testing and pentesting should also include testing at the API layer. We regularly test UIs for injection vulnerabilities and the OWASP TOP 10, we should consider OWASP API Top 10 as well.
• More organizations should embrace bug bounty programs and independent testing to complement their internally planned periodic application testing.
• Regularly update and patch. Keep up to date with your third-party APIs that you consume.
• Inventory. Maintain an up-to-date asset inventory, specifically document all your bespoke and custom software, as well as any third-party code or APIs used in custom and third party applications.
• Consider attack protection solutions like a WAF, API Gateways that can provide some protection such as input validation, user authentication, access controls, rate limiting, IP and geographic whitelisting.
• Implement strong access control across the systems and its underlying components, servers, containers, databases, network devices and API consoles. Consider least privilege, segregation of access, RBAC, and using of a robust access matrix to map out all user types in the application and corresponding access. In addition, monitoring of the access rules to detect any changes and if there are toxic combinations of access.
• API testing should include both functional and non-functional testing. Currently only about 4% of API testing is focused on security.
• Code reviews should include new and emerging vulnerabilities. Especially, related to third party libraries and APIs.
• Authorization should be implemented within the application logic itself, not only at the API gateway or other access point but to confirm rights and permissions.
• Logging and monitoring must cover everything. Not just server, OS, DB logs but also application logs, API gateway logs. Using a SIEM can help with this, but your applications should be able to generate these logs.
• Security should be baked into the entire application lifecycle, from design, to product, to retirement of the APIs.
• Internal APIs are equally susceptible to attacks. Don’t treat them as inherently secure.
• Relying on UI for security is a bad idea, attackers can go around the UI and call the API directly to exfiltrate raw and unfiltered data.
• Constitute an API standard or policy just as we have other standards to aid the lifecycle of the APIs including security and compliance.

Thanks for reading.