REST API Security: The Checklist Most Teams Skip

Most REST API breaches don't happen because of some exotic zero-day. They happen because of misconfigured auth, missing rate limits, verbose error messages, or a CORS policy that's basically "allow everyone." These are boring problems with boring fixes — but they get skipped under deadline pressure, and then they show up in a breach report six months later.

Here's a practical breakdown of what actually secures a REST API in production, not just in theory.

1. Fix Authentication Before Anything Else

If your API's auth is weak, nothing else on this list matters much. Get these right first:

Use tokens, not basic auth

• Prefer OAuth 2.0 or signed JWTs over sending username/password on every request.
• Set short expiry times on access tokens (15–60 minutes) and use refresh tokens for longer sessions.
• Never put sensitive data (roles, PII) in a JWT payload unless it's encrypted — JWTs are signed, not encrypted, and anyone can base64-decode the payload.

Validate tokens on every request

Don't just check that a token exists — verify the signature, check expiry, and confirm the issuer. A surprising number of APIs check for a token's presence but skip signature validation on internal microservice calls, assuming "it's internal, it's fine." It isn't.

Rotate and scope API keys

• Issue separate keys per client/integration, not one shared key for everyone.
• Scope keys to specific endpoints or permissions (read-only vs. write access).
• Build in key rotation from day one — retrofitting rotation into a live system with hardcoded keys is painful.

2. Enforce HTTPS Everywhere, No Exceptions

This sounds obvious, but it's routinely broken in practice:

• Redirect all HTTP traffic to HTTPS at the load balancer or reverse proxy level — don't rely on the application to do it.
• Use HSTS (HTTP Strict Transport Security) headers so browsers refuse to downgrade to HTTP even if a link points there.
• Check for mixed content — internal API calls between microservices should also be encrypted, not just the public-facing endpoint.
• Renew TLS certificates before they expire and monitor for weak cipher suites (TLS 1.0/1.1 should be disabled entirely).

SSL misconfiguration is one of the most common issues we see when scanning APIs with WebSentry — expired certs, weak ciphers, or certificates that don't cover all subdomains being hit by the API gateway.

3. Lock Down Rate Limiting and Throttling

Without rate limits, your API is an open invitation for credential stuffing, scraping, and brute-force attacks.

1. Set per-IP and per-key limits — e.g., 100 requests/minute for anonymous, higher for authenticated clients.
2. Return proper 429 status codes with a Retry-After header so legitimate clients back off gracefully.
3. Apply stricter limits to sensitive endpoints like /login, /reset-password, and /api/search — these get hammered first.
4. Use a sliding window or token bucket algorithm instead of fixed windows, which are trivially gamed by timing requests around the reset.

4. Get Security Headers Right

APIs often get overlooked when teams set up security headers, since the assumption is "headers are for websites, not JSON endpoints." That's a mistake — headers still matter for any API consumed by browsers.

• Content-Security-Policy (CSP): relevant if your API serves any HTML (docs pages, error pages, admin dashboards).
• X-Content-Type-Options: nosniff — stops browsers from guessing content types in unexpected ways.
• Strict-Transport-Security — as mentioned above, enforce HTTPS at the browser level too.
• Cache-Control: no-store on endpoints returning sensitive data, so responses aren't cached in browser history or shared proxies.

Checking headers manually across every environment (staging, production, regional deployments) gets tedious fast. This is exactly the kind of thing a WebSentry scan flags automatically — it grades your headers, CSP, and SSL config together so you're not chasing each one separately.

5. Nail Down CORS — Don't Just Allow Everything

The fastest way to "fix" a CORS error during development is to set Access-Control-Allow-Origin: *. The fastest way to create a security hole is to leave that in production.

• Whitelist specific origins explicitly — don't use a wildcard if the endpoint handles authenticated requests or cookies.
• Never combine Allow-Origin: * with Allow-Credentials: true — browsers block this combination for good reason, and if you've bypassed it somehow, that's a red flag.
• Review your CORS policy per environment — a permissive policy on a staging API often gets copy-pasted into production and forgotten.

6. Validate and Sanitize Every Input

REST APIs are prime targets for injection attacks because they accept structured input that's easy to script against.

• Validate types, lengths, and formats server-side — never trust client-side validation alone.
• Use parameterized queries or an ORM to prevent SQL injection; never concatenate raw input into queries.
• Reject unexpected fields in request bodies rather than silently ignoring them — this closes off mass-assignment vulnerabilities.
• Sanitize anything that gets reflected back in responses (especially in error messages) to avoid leaking internal data structures.

7. Don't Leak Information in Error Responses

A stack trace in a 500 response is a gift to an attacker. Common leaks to avoid:

• Database error messages revealing table/column names.
• Framework version numbers in default error pages.
• Detailed "user not found" vs. "wrong password" messages on login endpoints — use a generic "invalid credentials" for both to prevent user enumeration.

8. Set Cookie and Session Flags Correctly (If You Use Them)

Some REST APIs still rely on cookies for session state, especially in hybrid web-app setups. If yours does:

• Set Secure so cookies only transmit over HTTPS.
• Set HttpOnly so JavaScript can't read the cookie (mitigates XSS token theft).
• Set SameSite=Strict or Lax to reduce CSRF exposure.

9. Check Your DNS and Subdomain Exposure

API security isn't just about the endpoint itself — it's about what's reachable around it. Old staging subdomains, forgotten admin panels, or DNS records pointing to decommissioned services are common entry points. Audit your DNS records periodically and remove anything that's no longer actively maintained or monitored.

Verify, Don't Assume

Every point above is easy to state and easy to skip under deadline pressure. The teams that actually stay secure are the ones who verify their configuration regularly instead of assuming it's still correct six months after launch — certificates expire, CORS policies get loosened "temporarily" and never get tightened back up, and headers get dropped during a server migration.

Run a free scan at websentry.dev and get an A–F grade across SSL, headers, CSP, cookies, DNS, and CORS in a couple of minutes — it's a fast way to catch exactly the kind of misconfigurations covered above before they turn into an incident report.