Misconfiguration, TLS and Headers

Every other category in this guide needs something to be wrong in the code. This one only needs a setting to be wrong, which is why it is the cheapest ground to cover and the easiest to leave uncovered.

OWASP lists it as API8:2023 Security Misconfiguration, and its references span CWE-16 for configuration, CWE-319 for cleartext transmission, CWE-209 for error messages that carry sensitive information and CWE-942 for permissive cross-domain policies.

Transport, and the versions you still accept

An API reachable over plain HTTP is an API whose tokens are readable by anyone on the path. That much is uncontroversial, and the part teams miss is that terminating TLS is not the end of the question.

RFC 8996, which is Best Current Practice 195, deprecates TLS 1.0 and TLS 1.1 and states that negotiating either of them must not be permitted. A host that still completes a handshake with one of them fails that document and most compliance baselines built on it. The fix is a configuration change at the load balancer or reverse proxy rather than anything in your service.

Two details make this easy to miss. A client that prefers a modern version will negotiate one, so everyday traffic looks fine while the old version stays available to whoever asks for it. And an HTTP client library normally hides the negotiated protocol, so checking this at all requires a deliberate handshake rather than an ordinary request.

Headers that cost nothing

Security headers do not fix a flaw. They remove a category of accident, and they are one line of configuration each.

Strict-Transport-Security, defined in RFC 6797, tells a browser to use secure transport for this host from now on, which closes the window where a first request goes out over cleartext. X-Content-Type-Options with the value nosniff stops a browser second-guessing your content type, which matters the moment a response you consider data is rendered as something else. Content-Security-Policy is aimed at documents rather than JSON, so it belongs on any endpoint a browser renders, including a documentation portal or an embedded console.

CORS, where the answer depends on the endpoint

A wildcard in Access-Control-Allow-Origin is not automatically a finding, and it is not automatically safe either.

On a genuinely public catalogue it is a deliberate decision that makes the API easier to use. On an endpoint that answers differently per caller, it lets any page in any tab read your responses through a visitor's browser. Because the specification forbids combining a wildcard with credentialed requests, cookie-authenticated APIs are partly protected by the rule itself, and APIs authenticated with a header token are not.

The workable position is that a wildcard needs a reason, written down once, per surface rather than globally.

What is still deployed that you forgot

Debug routes, profilers, actuator and management endpoints, metrics, and a specification browser that was handy during development all have a way of surviving into an environment that faces the internet.

Each of them is a different kind of gift. Some expose configuration, some expose internals, and some accept a command. The honest check is not whether you remember deploying them, because you do not, and it is whether a request to the usual paths gets an answer.

Error responses belong in the same section. A stack trace, a database message or a framework page tells an attacker which components you run and often which version, and CWE-209 exists for exactly that. The error design chapter covers what belongs in a failure body instead.

In Routebase

Two scanners split this category, because one of the checks cannot be made with an ordinary HTTP request.

api8-misconfig runs four checks. It reports a base URL that uses plain http://, missing Strict-Transport-Security, X-Content-Type-Options, X-Frame-Options or Content-Security-Policy on endpoint responses, a response carrying Access-Control-Allow-Origin: *, and successful answers from the paths /debug, /trace, /actuator and /actuator/health. Header and CORS checks probe each endpoint with a HEAD request and fall back to GET.

api8-tls-version exists because an HTTP client hides the negotiated protocol. It performs a dedicated TLS handshake against the target host once per run. A Medium finding at high confidence follows only when the host provably completes a handshake using TLS 1.0 or TLS 1.1. A plain-HTTP target is skipped rather than reported twice.

One false positive is worth anticipating. A reverse proxy that adds security headers above the origin makes those headers invisible to a scan pointed at the origin, so point the scan at the proxied URL that your callers actually use.

On the design side, the style guide rule must-use-https-server objects to a specification whose server URL is not https. Header policies are where a header set becomes a standard across specifications. They are a contract mechanism rather than a runtime one, so they apply headers to the responses in your specification rather than making your server emit them. See Header Policies and the Scanner Reference.