5 Objectives for Establishing an API-First Security Strategy

High visibility is crucial. An API-first approach is all about acknowledging the API as a first-class citizen in an application's design. Given the increase in vital work that the API does in communicating between applications, APIs must have the same scrutiny of access controls that a superuser (e.g., an IT administrative specialist with unlimited privileges) would.

That means an emphasis on visibility and accountability. If you can't see it, you can't account for it, and thus more visibility controls are needed for API security. The good news is organizations don't need to reinvent the wheel to get started. Web application firewalls (WAFs), OWASP vulnerability scanning tools, and smart use of Transport Layer Security (TLS) and proper authentication can all provide a consistent set of controls and visibility.

REST APIs are a growing target. REST (REpresentational State Transfer) is the duct tape of technology — it defines how systems can be connected to (and interact with) each other by using HTTP requests to access and use data. REST API usage has become so widespread in enterprise application development that many companies have difficulties defining a clear picture of all their deployments. These visibility gaps make APIs harder to protect.

Organizations must improve at keeping an accurate, up-to-date inventory of their REST use cases and employ secure channels like TLS and authentication keys to reduce risk.

Encryption of all data is key. This is true not just when data is at rest, but also in transit. In this encryption scenario, the API would use TLS and authorization tokens to transmit data securely, and the data that the API is accessing should also be encrypted. Remember that this encryption strategy is defense in depth; there's a classic military saying about the crucial need for redundancy that summarizes this idea well: "Two is one and one is none."

Credential stuffing is still a huge problem and an evolving threat. Credential stuffing is the practice of using an automated injection of stolen credentials to gain unauthorized access. Companies have gotten better at securing their front-end applications and webpages to defend against credential stuffing. Still, hackers increasingly have been targeting back-end APIs that historically tended to have fewer implemented security controls.

Evidence of this can be seen in a recent Akamai report that showed that one in every five attempts to gain unauthorized access to user accounts is now done through APIs rather than user-facing login pages. Companies must account for this trend in their API-first security strategy and do a better job of protecting back-end APIs from these attacks.

Automated checks should be standard practice. I'm repeatedly frustrated by how rarely I see automated security checks as part of a CI/CD pipeline, if they are implemented at all. A mature application security team should work with the engineering squads to design and incorporate security into pipelines and allow an organization to scale security with its product offerings.

Rather than asking why this practice isn't common, let's ask why it isn't more straightforward and cheaper to implement security in the CI/CD pipeline. Why do some developer tools not include features to make security checks more manageable? Why is it so expensive to audit for API security issues on running services? What are the dev tool vendors doing to improve this experience for their users and help developers punch above their security weight class?