OWASP API8 Security Misconfiguration Guide

An API can have flawless authorisation logic and still be breached through a debug endpoint, a permissive CORS policy, a verbose error or a logging library left on its defaults. OWASP API8:2023 Security Misconfiguration covers every layer of the API stack, from TLS termination and the gateway to the framework, the container and the cloud services behind it. This guide treats API8 as a requirement set: what the OWASP text asks for, the concrete settings that satisfy each item, the identity controls that misconfiguration usually undermines, the evidence an assessor should collect and how API8 maps to OWASP ASVS 5.0, NIST SP 800-53, NIST CSF 2.0, ISO/IEC 27001:2022 and CIS Controls. It is written for API developers, platform and SRE teams, and AppSec assessors. For the whole list see Top 10 API Security Risks.

Key takeaways

Misconfiguration is a stack problem, not an endpoint problem. OWASP places it anywhere from the network level to the application level, including permissions on cloud services such as storage buckets.
It is easy to find and easy to exploit. OWASP rates exploitability Easy, prevalence Widespread, detectability Easy and technical impact Severe, because automated scanners find the same gaps attackers look for.
Defaults are the root cause more often than mistakes. The OWASP Log4j style scenario relies on lookups enabled by default, and NSA and CISA list default configurations first among the ten misconfigurations their red and blue teams find most.
A repeatable baseline beats one-off reviews. OWASP asks for a hardening process, a configuration review across orchestration files, API components and cloud services, and automated continuous assessment in every environment.
Misconfiguration leaks machine credentials. Exposed environment endpoints, heap dumps, source control folders and open data stores hand attackers the API keys and service account secrets the API itself uses.

What it is and who it applies to

API8:2023 Security Misconfiguration is the eighth entry in the OWASP API Security Top 10 2023. OWASP describes attackers looking for unpatched flaws, common endpoints, services running with insecure default configurations and unprotected files and directories, noting that most of this is public knowledge and exploits may already exist. The impact ranges from exposure of user data to system details that can lead to full server compromise. The entry cites CWE-2 Environmental Security Flaws, CWE-16 Configuration, CWE-209 Generation of Error Message Containing Sensitive Information, CWE-319 Cleartext Transmission of Sensitive Information, CWE-388 Error Handling, CWE-444 Inconsistent Interpretation of HTTP Requests and CWE-942 Permissive Cross-domain Policy with Untrusted Domains.

API8 applies to every team that owns a piece of the request path:

Edge and gateway owners: CDN, WAF, load balancer and API gateway settings, TLS policy, header injection and request normalisation. See the API Gateway Security Guide.
Application developers: framework defaults, error handlers, CORS middleware, allowed methods and content types, management and documentation endpoints.
Platform teams: container images, Kubernetes manifests, Helm charts, service mesh policy and secrets injection. See the Kubernetes Security Guide.
Cloud owners: storage permissions, managed database exposure, serverless function URLs and IAM roles attached to API workloads. See the Cloud Misconfiguration Guide.

API8 overlaps with other entries but is distinct from them. A missing authentication check is API2, a missing authorisation check is API1 or API5, and an absent rate limit is API4. API8 is the settings, patches and defaults around that logic. A forgotten beta host that also lacks hardening sits across API8 and API9; see the OWASP API Top 10 API9 Improper Inventory Management Guide.

Structure and key requirements

The OWASP entry lists eight conditions under "Is the API Vulnerable?". The table turns each into a requirement with concrete settings and the matching ASVS 5.0 verification requirement, so that it can be tested.

OWASP condition	Requirement	Concrete settings and checks	ASVS 5.0
Hardening missing across the stack, or cloud permissions improperly configured	A documented hardening baseline per layer, applied by code	Production builds ship only required functionality; debug modes off; no directory listings; no `.git` or `.svn` folders deployed; storage and database endpoints private by default	V15.2.3, V13.4.1, V13.4.2, V13.4.3
Latest security patches missing, systems out of date	Risk-based patch timeframes for every component, including libraries	Documented remediation windows for third-party components; base image rebuilds on a schedule; KEV-listed flaws first	V15.1.1
Unnecessary features enabled (HTTP verbs, logging features)	Explicit allowlist of methods and features per endpoint	Return 405 for any method not allowlisted; disable TRACE; switch off JNDI style lookups and other dynamic expansion in logging; disable GraphQL introspection in production unless the API is public	V4.1.4, V13.4.4, V4.3.2
Servers in the HTTP chain process requests differently	Uniform message parsing across proxy, gateway and back end	All components determine message boundaries the same way; reject ambiguous `Content-Length` and `Transfer-Encoding` combinations; normalise at the edge. See the HTTP Request Smuggling Guide	V4.2.1
TLS missing	TLS on every hop, public and internal	No plaintext fallback on external services; TLS between internal services and to monitoring and management tools; HSTS on browser-reachable hosts	V12.2.1, V12.3.1, V12.3.3, V3.4.1
Security or cache control directives not sent	A standard response header set for API responses	`Cache-Control: no-store` on sensitive responses, `X-Content-Type-Options: nosniff`, a `Content-Type` that matches the body, `Content-Security-Policy: frame-ancestors 'none'` where browsers consume the API	V14.3.2, V3.4.1
CORS policy missing or improperly set	A fixed origin or an exact-match allowlist	No reflected arbitrary `Origin`; never allow `null`; no wildcard with credentials; send `Vary: Origin` when the value is chosen per request; disable CORS on APIs no browser calls	V3.4.2
Error messages include stack traces or other sensitive information	Generic errors to callers, detail to logs	A last-resort error handler; response schemas defined for errors as well as success; no backend version strings in headers or bodies	V16.5.1, V13.4.6

The two OWASP scenarios as test cases

Insecure logging defaults: a back end logs a request header using a logging utility with placeholder expansion and JNDI lookups enabled by default, and a permissive outbound network policy lets the lookup fetch and run a remote class. This is the pattern behind Log4Shell, CVE-2021-44228, which CISA added to its Known Exploited Vulnerabilities catalogue on 10 December 2021. Test that logging does not evaluate request data, and that API workloads cannot open arbitrary outbound connections.
Missing cache directives: a direct message endpoint returns private conversations without a Cache-Control header, so the browser caches them on disk. Test every authenticated response for no-store, and note the OWASP REST cheat sheet caveat that no-store does not stop caches the application manages itself.

Reference header set for API responses

The OWASP REST Security Cheat Sheet gives a core header set for API responses that browsers may consume. APIs called only by servers still benefit, because the cost is negligible and clients change over time.

Header	Value	Purpose
`Cache-Control`	`no-store`	Stops browsers and shared caches storing sensitive responses
`Content-Security-Policy`	`frame-ancestors 'none'` (plus `default-src 'none'` if responses could ever render)	Prevents framing and content execution in a browser
`Content-Type`	Matches the body, for example `application/json`	Prevents the browser interpreting the response in another context
`Strict-Transport-Security`	HSTS policy for HTTPS-only access	Blocks protocol downgrade on browser clients
`X-Content-Type-Options`	`nosniff`	Disables MIME type guessing
`X-Frame-Options`	`DENY`	Legacy framing protection for older browsers

The same cheat sheet asks for an allowlist of HTTP methods with 405 for everything else, 415 for unsupported request content types and 406 only for failed response negotiation. See the Security Headers Guide and the CORS Misconfiguration Guide.

Choosing where to enforce

Layer	Best for	Weakness
API gateway or edge	TLS policy, header set, method allowlist, request normalisation, blocking management paths	Services reachable around the gateway keep their own defaults
Framework configuration	Error handling, CORS, actuator and debug endpoints, content negotiation	Repeated per service; drifts without shared templates
Infrastructure as code and admission policy	Private storage, network policy, non-root containers, no public load balancers without approval	Does not see application behaviour
Runtime scanning (DAST, cloud posture)	Catching what slipped through, in every environment	Finds problems after deployment

Small teams get most value from one service template that sets headers, errors, CORS and management endpoint exposure, plus a gateway policy that all public traffic must pass. Larger estates should express the baseline as policy as code in the pipeline and in cluster admission control, so a non-compliant manifest fails before it deploys. See the Infrastructure as Code Security Guide.

Identity and NHI requirements

Many API8 findings matter because they expose the credentials the API uses to reach databases, queues, cloud services and partners. Treat those machine identities as part of the hardening baseline.

Management endpoints are credential stores: framework endpoints that show environment properties, configuration or heap dumps can reveal connection strings and API keys. In Spring Boot, only health is exposed over HTTP by default; a broad management.endpoints.web.exposure.include=* changes that, and the documentation recommends securing endpoints whenever an application is publicly reachable. Keep management interfaces on a separate port or network and require strong authentication, as the OWASP REST cheat sheet advises.
No secrets in images, repositories or environment dumps: inject secrets at runtime from a secrets manager, and keep source control metadata out of deployments (ASVS V13.4.1). Exposed .git folders remain a common source of leaked deployment credentials. See the Secrets Management Guide.
Default-open data stores leak keys at scale: in Firebase Misconfigurations 2024, databases left reachable without authentication exposed over 19.8 million secrets, including plaintext credentials and API keys.
Least privilege for the API's own identity: the workload identity or service account behind an API should reach only the resources it needs. A hardening gap then exposes one service, not the whole cloud account. See the Service Account Security Guide.
Mutual TLS for service-to-service traffic: internal TLS (ASVS V12.3.3) combined with certificate-based workload authentication means a misrouted or smuggled request cannot impersonate a trusted internal caller. See the mTLS Guide.
Restrict outbound traffic from API workloads: the OWASP logging scenario only works because outbound network policy was permissive. An egress allowlist also limits where stolen workload credentials can be used from inside.

Implementation steps

Define the baseline. Write a short, testable hardening standard per layer: edge, gateway, framework, container, cluster, cloud. Use the eight OWASP conditions and the ASVS requirements in the table above as the skeleton, and CIS Benchmarks for operating systems and Kubernetes where you use them.
Ship secure templates. Publish a service template and gateway policy that set headers, CORS, method allowlists, generic error handling, TLS and closed management endpoints by default. New services start compliant.
Codify and gate. Scan Terraform, Helm and Kubernetes manifests in the pipeline for public storage, public load balancers, privileged containers and plaintext listeners. Start in warn mode for one or two sprints, fix the backlog, then block merges.
Patch on a clock. Set remediation timeframes by severity, prioritise anything on the CISA KEV list, rebuild base images on a schedule and track library versions through an SBOM. See the Patch Management Guide.
Scan the running estate. Run authenticated DAST and header, TLS and CORS checks against every API hostname in every environment, not only production, plus cloud posture scanning for the services behind the APIs.
Normalise the HTTP chain. Align parsing behaviour between CDN, load balancer, gateway and back end; reject ambiguous framing at the edge and test for desync after every proxy change.
Detect drift. Compare running configuration with the baseline continuously and alert on changes made outside the pipeline.
Roll back safely. Ship header, CORS and method changes behind gateway policy versions that can be reverted in minutes; tighten CORS in report-only fashion first by logging rejected origins, and keep a known-good configuration for each service to restore after a failed change.

Evidence and assessment

Requirement	Evidence to request	Red flag
Hardening baseline	Written standard, service template, policy-as-code rules and their pass rate	Baseline exists only as a wiki page
Patching	Component inventory or SBOM, remediation timeframes, KEV exposure report	Base images older than the rebuild policy; KEV flaws open past deadline
Methods and features	Gateway method allowlists, DAST results for TRACE and unused verbs	Unexpected methods return 200; GraphQL introspection open on a private API
Transport security	TLS scan of every API hostname, internal mesh policy	Plaintext listeners internally, or management tools reached over HTTP
Headers and CORS	Automated header and CORS test results per hostname	Origin reflected verbatim; `null` allowed; credentials with broad origins
Error handling and disclosure	Sample error responses, framework error configuration	Stack traces, SQL fragments or version banners in responses
Management and debug endpoints	External scan of management paths, exposure settings	Environment, metrics or heap dump endpoints reachable from the internet

Verbose errors deserve particular attention because they shorten an attacker's work. In the McKinsey AI Platform Hack 2026, the researchers' agent found the API documentation publicly exposed, and error messages that reflected JSON field names helped it refine an injection over a series of blind attempts.

Detection signals and metrics

Signals to alert on: requests for known management and debug paths; unusual HTTP methods; 5xx bursts from a single client probing errors; responses containing stack trace patterns; configuration changes outside the pipeline; new public endpoints, buckets or load balancers.
Baseline compliance: share of API services passing all policy-as-code checks; target 100 percent for internet-facing services.
Header and CORS conformance: share of API hostnames returning the full header set and a non-reflective CORS policy.
Patch latency: median days from fix release to deployment for critical and KEV-listed flaws in API components.
Drift rate: configuration deviations detected per month, and mean time to restore the baseline.
Exposure count: management or documentation endpoints reachable from the internet; target zero unless explicitly intended.

Mapping to other frameworks

API8 area	NIST SP 800-53 Rev. 5	NIST CSF 2.0	ISO/IEC 27001:2022 Annex A	CIS Controls v8.1	MITRE ATT&CK v20
Hardening baseline and drift	CM-2 Baseline Configuration; CM-6 Configuration Settings; CM-3 Configuration Change Control	PR.PS-01	8.9 Configuration management	Control 4 Secure Configuration of Enterprise Assets and Software	T1190 Exploit Public-Facing Application
Unnecessary features and endpoints	CM-7 Least Functionality	PR.PS-01	8.9 Configuration management; 8.31 Separation of development, test and production environments	Control 4	T1595.002 Vulnerability Scanning
Patching	SI-2 Flaw Remediation; RA-5 Vulnerability Monitoring and Scanning	PR.PS-02; ID.RA-01	8.8 Management of technical vulnerabilities	Control 7 Continuous Vulnerability Management	T1190
Transport security	SC-8 Transmission Confidentiality and Integrity	PR.DS-02	8.24 Use of cryptography	Control 3 Data Protection	None specific
Error handling and disclosure	SI-11 Error Handling	PR.PS-01	8.28 Secure coding	Control 16 Application Software Security	T1592 Gather Victim Host Information
Continuous assessment	CA-7 Continuous Monitoring	DE.CM-09	8.16 Monitoring activities	Control 16	None specific

See the OWASP ASVS Guide for the full verification standard and the Top 10 Network Security Misconfigurations for the network layer beneath the API.

Common pitfalls

Hardening production only: staging and preview environments often run debug modes, open CORS and real data, and they are reachable from the internet. Apply the same baseline to every environment that can be reached.
Reflecting the Origin header: echoing whatever Origin arrives, with credentials allowed, is equivalent to no CORS policy. MDN notes that null should not be allowed either, because any page can create a document with a null origin.
Trusting the gateway alone: back ends reachable directly by pod or function URL keep their own defaults. Network policy should make the gateway the only path.
Turning on everything to debug: enabling all management endpoints during an incident and never reverting it. Make exposure settings part of the reviewed configuration, not a runtime toggle.
Error handlers per controller: a single unhandled exception path leaks a stack trace. Use a last-resort handler (ASVS V16.5.4) and define error response schemas.
Patching the code but not the image: dependency updates without base image rebuilds leave operating system and runtime flaws in place for months.

Practitioner checklist

Publish a testable hardening baseline per layer, mapped to the eight OWASP API8 conditions.
Start every service from a template that sets headers, CORS, methods, errors and TLS correctly.
Gate Terraform, Helm and Kubernetes changes with policy as code, warn first, then block.
Allowlist HTTP methods and content types per endpoint; return 405, 415 and 406 as appropriate.
Use TLS on every hop, including internal services and management tools, with HSTS on browser hosts.
Set Cache-Control: no-store on sensitive responses and a fixed or exact-match CORS policy.
Return generic errors with defined schemas and log detail server-side only.
Keep management, debug and documentation endpoints off the internet and authenticated.
Patch to documented timeframes, KEV-listed flaws first, and rebuild base images on schedule.
Scan every environment continuously for drift, exposed endpoints and missing headers.

OWASP API Top 10 API8 Security Misconfiguration Guide: Hardening the API Stack