API8:2023 Security Misconfiguration in the OWASP API Security Top 10 means any gap in hardening across the API stack: missing patches, unneeded features left on, absent TLS, loose CORS, or error messages that leak internals. It is easy to detect, so attackers and scanners find it first. Fix it with a repeatable hardening process.
What does OWASP say counts as vulnerable?
OWASP lists specific signs. Your API might be vulnerable if hardening is missing anywhere in the stack, or cloud permissions are wrong. It might be vulnerable if patches are missing or software is out of date, or if unnecessary features are enabled, such as extra HTTP verbs or logging features.
The list goes on. Servers in the request chain may handle requests differently from each other. TLS may be missing. Security or cache control directives may not be sent to clients. A CORS policy may be missing or set too loosely. Error messages may include stack traces.
OWASP rates exploitability as easy, prevalence as widespread and detectability as easy. That combination explains why this item shows up in so many incident write-ups. It needs no cleverness, only a missed setting.
The fix is as unglamorous as the flaw. Treat configuration as code: keep it in version control, review changes, and compare environments automatically. When staging and production differ, the difference is usually where a misconfiguration is hiding, and a diff finds it faster than a penetration test.
What do the OWASP examples teach?
Two scenarios are worth remembering.
In the first, an API server writes an access log using a popular third-party logging library that expands placeholders and supports JNDI lookups by default. A crafted request header gets written into the log, and the library fetches and runs a remote object. OWASP blames the insecure default plus a permissive outbound network policy. Two separate misconfigurations combined. Restricting outbound traffic from the server would have broken the chain even without a code fix.
In the second, a direct message API response has no Cache-Control header, so private conversations end up in the browser cache on disk. Nothing was hacked. A missing header exposed data on a shared computer.
Where do misconfigurations hide?
Not in the application code you review most. They hide in orchestration files, gateway settings, cloud storage permissions, default admin consoles, debug endpoints, and the differences between environments. OWASP specifically points reviewers at orchestration files, API components and cloud services such as storage bucket permissions.
They also hide in the chain. A load balancer, a reverse proxy and a backend may each parse a request slightly differently. OWASP links this to CWE-444, inconsistent interpretation of HTTP requests, which is the root of request smuggling. The advice is to make every server in the chain process requests in a uniform way.
How to check or apply this
- List every hop between the client and the data: CDN, gateway, load balancer, proxy, service. Confirm they agree on how to parse requests.
- Require TLS for all API traffic, including internal calls.
- Allow only the HTTP verbs and content types each endpoint needs, and disable the rest.
- Set a specific CORS policy for browser clients, not a wildcard, and send the security headers that apply.
- Define response schemas, including for errors, so stack traces never reach clients. Turn off verbose debug output outside development.
- Send cache control directives on responses that carry private data.
- Limit outbound network access from API servers to what they truly call.
- Automate a configuration check that runs in every environment on a schedule, and compare staging with production.
- Keep libraries and base images patched, and track defaults in new dependencies.
If your team tracks dependencies, treat an upgrade that changes a default as a configuration change and review it as one. Safeguard's dependency scanning and policy gates can flag outdated libraries during a pull request, which covers one slice of this item; the rest is configuration review.
Quick check
Is API8 only about cloud settings?
No. OWASP covers the whole stack, from network level to application level, including patches, default features, headers, CORS and error handling.
How often should configurations be reviewed?
OWASP recommends a task to review and update configurations across the API stack plus an automated process that continuously assesses settings in all environments.
Sources
Last reviewed: 18 October 2026.
