At APIsec University we talk to lots of companies and hear what’s working, what’s not, and what they’re focusing on for 2024. This list should be a lot more than 10 items long, but these are the ones that we heard repeatedly throughout 2023.

‍

1. Start with Governance

It’s very tempting for teams to jump right into “fixing” API security. But long-lasting API security needs to be developed from the ground up. So start with Governance - get all the teams together (dev, sec, ops, compliance, risk, …) and talk about your API requirements: what is the role of APIs in our organization, how do we ensure consistency across APIs, where are APIs managed?...

‍

2. Know Your API Ecosystem

You can’t secure what you don’t know. So make sure you know your entire API ecosystem. What APIs you have, what data do they access, who owns it, where is it deployed,...

Many security teams complain of poor API visibility. We recommend starting by getting Security and Development talking (see #3). I guarantee the Dev team has a good idea of what APIs exist and what’s coming. Consider creating an API Marketplace where developers can publish their work and make it accessible.

‍

3. Get Security and Development talking

Security and Development teams are often too isolated. Security needs to be woven into the DNA of APIs - in the application logic and code itself. That requires Dev teams to be part of the security effort and to own some of the responsibility for keeping APIs free of logic flaws, authorization gaps and other vulnerabilities. Security cannot be bolted on after the API has gone live.

‍

4. API Docs are Non-Negotiable

Too many APIs lack documentation, or have weak, outdated documentation. This needs to be mandatory. It’s not just important for users of your APIs - it also seriously aids the security effort. With documentation you give security teams great insight into what your API does, what inputs it accepts, what functionality it performs. And it helps test creation to ensure those APIs are free of vulnerabilities.

We’ve got a great course on Best Practices for API Documentation - https://www.apisecuniversity.com/courses/api-documentation-best-practices

‍

5. Train API Devs/Owners

As mentioned in #3, Dev teams need to share responsibility for API security - so we need to make sure they’re aware of API risks and trained on security best practices. We recommend having API developers and product owners take the API Security Fundamentals course. It’s only 90 minutes, covers the OWASP API Top 10, reviews real-world breaches, and provides best practices for API security - https://www.apisecuniversity.com/courses/api-security-fundamentals

‍

6. Centralize API Management 

We hear a lot about “shadow” and “rogue” APIs. These are APIs you don’t know about that somehow got created and published. We believe no APIs should get deployed without going through a standardized, well-defined process (see #1). And if you’ve got rogue/shadow APIs, you’ve got a Governance problem. One of the best ways to improve is to require all APIs to be deployed and managed in a centralized API Gateway.

‍

7. Don’t Trust Anything

This is simple - don’t trust anything coming into your APIs. I.e., perform strong input validation. If your API has an input for a LinkedIn profile URL, but someone inserts /etc/passwd, or malware link, or really anything that doesn’t look like a LinkedIn URL - just throw it away. Make sure every input gets checked before doing anything with it.

‍

8. Don’t rely on UIs for Security

UIs are great places to control what data users can see, what buttons they can click, etc. The problem is attackers will find the APIs powering your UI hit them directly - bypassing all those controls. If you filter data at the UI, that means the API is returning more than needed. If you limit which buttons a user can press in the UI, an attacker is going to try exercising those API endpoints directly.

‍

9. Authentication != Authorization

There are countless examples of API breaches where an attacker was able to leverage an API to access records of other users. This is textbook BOLA (Broken Object Level Authorization), and it’s number 1 on the OWASP API Security Top 10 for good reason. 

Many organizations enforce authentication on their APIs and think they’re done. The API iås locked down, you have to present valid credentials to access it. But once authenticated, thåçe attacker uses the API to request another user’s record - often by incrementing a UserID. That is an authorization flaw and needs to be addressed in the app logic directly.

‍

10. Automate Pre-Production API Testing

Most organizations these days push new code into production every month/week/day. But API security testing is still largely manual, often performed once or twice a year by pen-test teams. There’s a huge mismatch in the pace of development and frequency of testing. So releases go live without thorough security testing.

What’s needed is shift-left testing - where APIs get tested on every release, against a comprehensive suite of attack scenarios, as part of the CI/CD pipeline. That way testing keeps pace with releases, and no APIs go live without proper vetting. And the only way to achieve this is to automate test creation and execution, and integrate with pipelines and ticketing systems.