What are the top security vulnerabilities to avoid in API development?

I've found that some dev and engineering teams stick with standard API keys. The problem is the non-repudiation aspect of it and you're heavily reliant on secure secrets management at runtime. When using AuthN OIDC in modern cloud is a great pattern to enforce. There are many templates such as federation via OIDC using AWS IAM Roles or GCP Service Account patterns for JIT AuthN for CI runners. I see API keys staying for a while among many integrations but would encourage transitioning to compatible protocols that can work with FIDO2 standards as we evolve our IAM needs beyond just interactive users.

In API development, the top security vulnerabilities to avoid include: Insecure Direct Object References (IDOR): This critical vulnerability occurs when an API exposes a reference to an internal implementation object, such as a file, directory, or database key, without proper authorization checks. Injection Flaws: SQL, NoSQL, OS, and LDAP injection flaws occur when untrusted data is sent to an interpreter as part of a command or query. Broken Authentication: Improperly implemented API authentication mechanisms can allow attackers to compromise authentication tokens or exploit implementation flaws. Lack of Resource and Rate Limiting: Without proper restrictions, APIs can be vulnerable to DoS attacks.

Standardized authentication protocols, multi-factor authentication are a good way to ensure your api is secure. Another way to secure your API is to ensure your tokens like JWT tokens have expirations and are actively checked before allowing a request to hit the endpoints. All of these together help reduce the chances of exploitation.

One of the first things that comes to mind is "infrastructure, infrastructure, infrastructure" and so many auditors turn to the now commonplace WAF. It's not the pancreas just as IPS or EDR isn't. Continue to layer, including instrumenting your code with the use of secure package layers and RASP. There are too many data and connectivity junctions that can't be easily tracked economically without protection application specific runtime protection. For note in high performance throughput, consider utilizing solutions and/or vendors that compute closet to your workload. Latency does add up at invocations when relying on SaaS providers.

Always hide sensitive information when it comes to exposing information to the UI. Any debugging or error logging should not be displayed to the front end and should be stored internally. Displayed error messages must be concise and consistent without being over explanatory to an end user. This will help identify issues while keeping sensitive system information secure.

App level testing is so much more than web app vuln scanning (DAST) and pen testing. On the testing aspect, many smaller or newer teams don't include full testing in their CI's during build or non-prod deployment stages. Lots of software composition analysis (SCA) for vulnerabilities and static code testing (SAST). But rarely do I see integrated the DAST level scans (OWASP ZAP supports in Jenkins plugins for example) and even more rare tests that occur after or as part of integration testing. My experience has shown shift-left testing in pieces. Runtime level testing can be expensive, but you can use self-hosted customized runners or instrumented BAS to support this. As a Detection Engineering collective whole, we can do better.