Quick answer: Build security into an API from the design stage, not after the deadline. Serve it only over HTTPS. Authenticate every caller, and check authorisation on every object and function they touch. Keep API keys and tokens out of URLs. Validate all input and use parameterised queries to stop injection. Return generic error messages without stack traces. Rate-limit requests and log security events. The OWASP API Security Top 10 (2023 edition) is the most widely used checklist for these risks.
When you develop an API, security should be one of the first questions you address, but it often is not. Some teams look for shortcuts to ship before a deadline and plan to “add security later”. That leaves the API, and every app that relies on it, open to attack. Think of it like documentation: if you skip a proper API documentation service and leave the docs in a mess, nobody will want to use your API. Skip security, and the people who do use it are put at risk. (Stoplight, the documentation tool linked here, is now part of SmartBear.)
This guide keeps the five practices from the original version of this article, corrects some technical mistakes it contained, and adds the risks that the Open Worldwide Application Security Project (OWASP) now ranks highest for APIs.
1. Do not leak stack traces in error responses
The original article said that “stack traces such as 200, 404 and 500” are commonly used. That mixed up two different things:
- HTTP status codes (200 OK, 404 Not Found, 500 Internal Server Error and so on) tell the client what happened. You should use them, and pick the most accurate one rather than returning 200 or 404 for everything.
- Stack traces are the internal list of function calls at the moment of an error. They can reveal file paths, frameworks, library versions and code structure to an attacker.
The original’s fix was right: return an error object with a suitable HTTP status code, and never show the stack trace. OWASP’s REST Security Cheat Sheet says to respond with generic error messages and not to pass technical details, such as call stacks, to the client. Log the full details on the server instead.
2. Limit request rates and guard against replay
The original section on “replay attacks” really described a different problem: public APIs receive huge numbers of requests, and some of them are malicious. Two separate defences are needed.
Rate limiting
OWASP’s 2023 list includes “Unrestricted Resource Consumption” (API4). Every request uses bandwidth, CPU, memory or paid third-party services such as SMS, so an API without limits can be knocked offline or run up large bills. Set limits per client, return HTTP 429 (Too Many Requests) when they are exceeded, as OWASP’s cheat sheet recommends, and monitor your traffic. The original article’s advice to use tools that analyse request traffic fits here.
Replay protection
In a replay attack, someone captures a valid request or token and sends it again. Use HTTPS so that requests cannot easily be captured in transit. Use short-lived tokens; JSON Web Tokens (JWTs) carry an expiry time. When you need to revoke a token early, OWASP suggests denylisting its unique identifier (the “jti” claim). For multi-step flows, such as a checkout, check on the server that each step happens in the right order, so that a reused token cannot skip ahead.
3. Require authentication, and check authorisation everywhere
An API with no authentication is a threat to every app that uses it. The original article said authentication should be put in place “after the API is fully designed”. It is better to design it in from the start, because retrofitting it is where gaps appear.
- Use established systems. OWASP recommends centralising user authentication in an identity provider that issues access tokens, rather than inventing your own scheme. Broken Authentication is number two (API2) on OWASP’s 2023 list.
- Check authorisation on every object. The top risk on OWASP’s list (API1) is Broken Object Level Authorization. Any endpoint that takes an ID, such as /orders/123, must check that the caller is allowed to see that particular record.
- Check authorisation on every function and property. OWASP also lists Broken Function Level Authorization (API5) and Broken Object Property Level Authorization (API3). Admin functions and sensitive fields need their own checks.
- Do not rely on API keys alone. OWASP says API keys help against abuse but should not be the only protection for sensitive or high-value resources.
4. Keep API keys out of URLs
This advice from the original still stands. Keys and tokens placed in a URL (for example ?apiKey=…) can end up in web server logs, proxy logs and browser history. OWASP’s cheat sheet says passwords, security tokens and API keys should not appear in the URL. Send them in a request header instead, usually the standard Authorization header, or in the body of POST and PUT requests.
The original also claimed that headers are “not logged by network elements”. That is too strong. Headers are less likely to be logged than URLs, but you should still make sure your own logs and monitoring tools mask them.
5. Prevent injection attacks
The original described injection as a hacker gaining access to an API’s backend code. More precisely, injection happens when untrusted input is passed to an interpreter, such as a database, an XML parser or an operating-system shell, and treated as a command or query. A successful SQL injection can read, change or delete data the attacker should never touch.
Common types include:
- SQL and NoSQL injection: prevented by parameterised queries or prepared statements, never by building query strings from user input.
- XML attacks: such as XML External Entity (XXE) attacks, prevented by configuring XML parsers to disable external entities.
- Command injection: prevented by not passing user input to shell commands at all.
- Regular-expression abuse: the original listed RegEx injection. A common risk with regular expressions in APIs is “ReDoS”: a crafted input that makes a badly written pattern run for a very long time. Test your patterns and limit input length.
OWASP’s cheat sheet adds general input validation: check the length, range, format and type of every parameter, use strong types such as numbers and dates, and reject unexpected content. Injection was a separate category (API8) in OWASP’s 2019 API list. The 2023 edition no longer lists it on its own, but it remains a basic defence every API needs.
The OWASP API Security Top 10 (2023) at a glance
| ID | Risk | What it means in one line |
|---|---|---|
| API1 | Broken Object Level Authorization | Callers can access records that belong to others by changing an ID. |
| API2 | Broken Authentication | Flawed login or token handling lets attackers pose as users. |
| API3 | Broken Object Property Level Authorization | Callers can read or change fields they should not. |
| API4 | Unrestricted Resource Consumption | No limits, leading to outages or large bills. |
| API5 | Broken Function Level Authorization | Ordinary users can call admin functions. |
| API6 | Unrestricted Access to Sensitive Business Flows | Automated abuse of flows such as purchases or sign-ups. |
| API7 | Server Side Request Forgery | The API can be tricked into fetching attacker-chosen URLs. |
| API8 | Security Misconfiguration | Unsafe default or forgotten settings. |
| API9 | Improper Inventory Management | Old API versions and debug endpoints left exposed. |
| API10 | Unsafe Consumption of APIs | Trusting data from third-party APIs too much. |
A short pre-launch checklist
- HTTPS only, with no plain HTTP endpoints.
- Authentication through an established identity provider, plus authorisation checks on every object, property and function.
- Keys and tokens in headers, never in URLs; short-lived tokens.
- Input validation and parameterised queries everywhere.
- Generic error messages with accurate status codes, and no stack traces.
- Rate limits with HTTP 429 responses, plus audit logs for security events.
- An up-to-date inventory of every API version and endpoint, with old ones retired.
If you are explaining to colleagues why APIs matter in the first place, our introduction to what APIs are and how they help a business grow is a good starting point. APIs often carry customer data, so our guide on protecting customer identity online is also relevant.
Frequently asked questions
What is the OWASP API Security Top 10?
A list of the most critical API security risks, published by the OWASP API Security Project. The current edition is from 2023, and Broken Object Level Authorization is at the top.
Are HTTP status codes a security risk?
No. Accurate status codes are good practice. The risk is detailed error messages and stack traces in the response body, which can reveal how your API is built.
Where should an API key go in a request?
In a request header, usually the Authorization header, not in the URL. Keys in URLs can end up in logs and browser history.
Is an API key enough to secure an API?
Not for sensitive data. OWASP says API keys can reduce abuse, but should not be the only protection for sensitive or high-value resources. Use proper authentication and authorisation as well.
Checked in October 2026 against the OWASP API Security Top 10 (2023) and the OWASP REST Security Cheat Sheet. This is a general guide; follow your framework’s own security documentation as well.
