PC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11Crashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minuteiTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
To secure an API, test each of the ten risk areas in the OWASP API Security Top 10 (2023 edition) against your own routes, identities, data, roles, workflows, network boundaries and integrations, then fix the gaps that apply. Four controls do most of the work: check authorization on every object a client can name by ID, treat login, account recovery and sensitive account changes as high-risk flows, limit resource-heavy and business-critical actions, and never trust data returned by an external API. The rest of this guide shows where each control belongs in a real API and how to verify it.
What the OWASP list can and cannot tell you
The OWASP API Security Top 10 is a risk checklist and an awareness document. It is not a complete implementation standard, and the project states that it does not replace other Top 10 lists. Use it to decide what to review and what questions to ask of each endpoint, then rely on protocol specifications and your platform’s own documentation for the detailed implementation. OWASP Top 10 API Security Risks – 2023 sets out the ten categories, and the project’s methodology and data page explains how they were chosen.
Two limits matter when you use the list to prioritise work. First, the ordering is not a statistical ranking of how often each weakness occurs. OWASP says its 2023 public call for data did not produce data suitable for relevant statistical analysis, so the prevalence ratings were set by consensus among project team members based on their experience. Second, the list does not prove that any particular API has any particular weakness. Its job is to structure your review.
This article uses the 2023 edition, which the project describes as its second edition. Check the OWASP API Security Project page for any later edition before you rely on the category numbers.
#1 Best Overall
Map the risks to the surfaces your API actually exposes
Most API reviews fail because they start with a generic checklist instead of the list of places where a request can reach data, change state or trigger work. Start with the surface, then ask which OWASP category applies to it.
| API surface | Typical example | OWASP 2023 category | What to verify |
|---|---|---|---|
| Identifiers and object access | GET /api/invoices/8841, or an ID in a body or query string |
API1 Broken Object Level Authorization | The caller is authorized for that specific object, not just for the route |
| Authentication and recovery | Login, token refresh, password reset, MFA enrolment | API2 Broken Authentication | Brute-force protection, re-authentication for sensitive changes, correct token and key use |
| Object properties | A PATCH body that accepts role or isAdmin |
API3 Broken Object Property Level Authorization | Each readable and writable field is checked for the caller |
| Resource-intensive operations | Exports, search, report generation, file processing | API4 Unrestricted Resource Consumption | Request limits, size limits, and the cost of dependent services |
| Privileged functions | /admin/users, bulk delete, configuration endpoints |
API5 Broken Function Level Authorization | Role and permission checks on each administrative function |
| Business workflows | Coupon redemption, ticket purchase, account signup, inventory holds | API6 Unrestricted Access to Sensitive Business Flows | Abuse controls for automated or excessive use of the flow |
| Outbound requests | Webhook URLs, image import from a URL, server-side fetches | API7 Server Side Request Forgery | Validation of user-supplied destinations before the server fetches them |
| Configuration | Debug settings, permissive cross-origin rules, default credentials | API8 Security Misconfiguration | Ongoing review of API and supporting-system settings |
| Hosts, versions and endpoints | Old /v1 routes still live, forgotten debug endpoints |
API9 Improper Inventory Management | An accurate, current inventory of hosts, versions and endpoints |
| Third-party integrations | Payment, shipping or identity providers called by your API | API10 Unsafe Consumption of APIs | Transport security, authentication, and validation of returned data |
These are risk areas, not a claim that every API has every weakness. An API with no outbound fetches has no server-side request exposure to review, but it should still record that decision.
Object-level authorization (API1)
OWASP’s guidance is that object-level authorization checks should be considered in every function that accesses a data source using a user-supplied ID. This is the most common place where an API checks that a user is logged in but not that the user owns the record they asked for.
The fix is to put the ownership or permission test in the data query or in a check immediately after the lookup, not in the client or the route alone. The following pattern shows the difference.
-- Vulnerable: any authenticated user can read any invoice by ID
SELECT * FROM invoices WHERE id = :invoice_id;
-- Safer: the query can only return rows the caller is allowed to see
SELECT * FROM invoices WHERE id = :invoice_id AND account_id = :caller_account_id;Test this with two accounts. Log in as account A, capture an object ID that belongs to A, then replay the request with account B’s token. A correct API returns an error or a not-found response. Also repeat the test for IDs placed in the path, query string and request body, because each one can select data.
Rank #2
Authentication: more than issuing a token (API2)
OWASP’s guidance on API2 treats authentication as a set of flows, not a single login endpoint. Protect login and credential recovery, require re-authentication for sensitive changes, use multi-factor authentication where possible, and apply anti-brute-force mechanisms.
Treat password recovery like login
OWASP recommends that credential recovery and forgotten-password endpoints receive the same brute-force, rate-limiting and lockout protections as login endpoints. Recovery endpoints are often left unprotected because they do not return a session, but they can still be used to enumerate accounts or guess reset codes.
Re-authenticate before sensitive changes
OWASP recommends re-authentication for sensitive operations such as changing the account owner’s email address or the phone number used for two-factor authentication. A stolen session should not be enough to take over the account by changing the recovery channel. Pair this with multi-factor authentication where your identity model supports it, and with weak-password checks at registration and password change.
Use API keys for clients, not users
OWASP’s API2 page states: “API keys should not be used for user authentication. They should only be used for API clients authentication.” Use API keys to identify a calling application, and use user-level credentials to identify a person. The same page makes a related point: “OAuth is not authentication, and neither are API keys.” OAuth delegates authorization, so a design that uses an access token as proof of who the user is still needs a proper authentication step, such as an OpenID Connect identity check or a verified login, before trusting the identity.
Property and function authorization (API3 and API5)
Object-level checks answer whether the caller can access a record. Property-level and function-level checks answer narrower questions.
Rank #3
Property-level authorization (API3)
Authorize reads and writes field by field. A common failure is a generic update handler that copies every submitted field into the model, so a customer can set role, credit_limit or email_verified. Use an explicit allow-list of writable fields for each caller type, and filter response bodies so that internal fields are not disclosed.
Function-level authorization (API5)
Check the caller’s role and permissions on every privileged or administrative function, not only in the user interface. Hidden admin routes and routes that are not linked from the client are still reachable, so the check belongs in the server-side handler or the gateway policy that protects it.
Resource consumption and sensitive business flows (API4 and API6)
OWASP lists unrestricted resource consumption and unrestricted access to sensitive business flows as separate risks. The first is about technical capacity and cost. The second is about abuse of legitimate functionality, which can look normal in server logs.
Limit resource-intensive requests (API4)
Set limits on request size, page size, result count, file size and the number of requests per client, and add a cap for expensive operations such as exports or report generation. OWASP also asks teams to consider costs that accrue through dependent services, such as per-call charges from a messaging, mapping or AI provider. A limit that protects the database may still leave a large billing exposure.
Protect business flows from automation (API6)
Identify flows that can harm the business when they are automated or used excessively, such as coupon redemption, seat or inventory holds, account creation and bulk purchases. Apply controls that match the abuse: per-account and per-device limits, verification steps for high-value actions, and monitoring that flags unusual sequences rather than only unusual volumes. A flow can be abused without a single malformed request.
Do these 3 things before closing this tab:
1Scan for outdated or missing drivers - takes under a minute2Repair Windows errors before they cause bigger problems3Fix the driver behind crashes, sound loss and screen glitchesRank #4
- API Security in Action
- Manning Publications
- ABIS BOOK
Outbound requests and third-party APIs (API7 and API10)
Both categories involve data moving across a boundary your code does not fully control: a URL that your server fetches, or a response that a third party sends back.
Validate destinations before fetching (API7)
If your API fetches a URL supplied by a client, validate the destination before the request is made. Allow only the schemes and hosts you need, resolve and check the destination address, and block internal network ranges and cloud metadata addresses. Apply the same check after redirects, because a permitted host can redirect to an internal one.
Verify third-party endpoints and their data (API10)
OWASP’s API10 page states: “Developers tend to trust and not verify the endpoints that interact with external or third-party APIs, relying on weaker security requirements such as those regarding transport security, authentication/authorization, and input validation and sanitization.” Apply the same security requirements to integrations that you apply to your own clients: use transport security and verify certificates, authenticate to the provider with the credentials it issued, and validate and sanitize every field you take from the response before storing it, rendering it or passing it to another system.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Configuration and inventory (API8 and API9)
These two categories are operational. They fail when a secure build drifts over time.
Security misconfiguration (API8)
Review the configuration of the API and its supporting systems as an ongoing task, not a one-time release check. Items to review include debug modes, verbose error messages, cross-origin rules, default credentials, unnecessary HTTP methods, and the settings of gateways, databases and storage that the API depends on.
Best Value
Improper inventory management (API9)
OWASP flags improper inventory because undocumented or deprecated versions and exposed debug endpoints can remain available. Keep an accurate list of every host, deployed API version and endpoint, and record which are public, internal and scheduled for retirement. Retire old versions on a schedule and verify that the gateway no longer routes to them. A version you have stopped documenting is still an attack surface if it still answers requests.
A review sequence for an existing API
If you are reviewing an API that is already in production, work in this order. Inventory comes first because every other check depends on knowing which endpoints exist.
- Build the inventory (API9). List every host, version, route and method, including those exposed only through a gateway or a legacy host. Mark each as public, partner-only or internal.
- Map identities and objects (API1, API5). For each route that takes an ID, record which roles should reach it. Then run the two-account test described above.
- Review authentication flows (API2). Confirm that login, recovery, token refresh and sensitive account changes each have brute-force protection and re-authentication where the change is sensitive.
- Check write and read fields (API3). Compare each request schema with the fields the caller should be able to change or see.
- Measure resource and business exposure (API4, API6). Identify the most expensive operations and the most valuable workflows, then confirm the limits and abuse controls that apply to each.
- Trace outbound calls (API7, API10). List every server-side fetch and every third-party dependency, then confirm validation at each boundary.
- Confirm configuration (API8). Check that the production settings match the approved baseline, and schedule the review to repeat.
Where the list stops
The OWASP list tells you what to review. It does not tell you which product, framework or architecture to choose, and it does not replace the specifications and platform guidance that govern each protocol and service you run. Use the OWASP categories as the structure for your review, and use your own endpoint inventory as the evidence.
Quick wins for a faster PC:
Clear out junk files and repair common Windows errorsFree Scan →Scan for outdated or missing drivers - takes under a minuteDriver Scan →Repair Windows errors before they cause bigger problemsFix Now →OWASP’s public statements in this article are taken from the 2023 edition pages linked above. Because the category numbering and wording can change between editions, confirm the current version on the project site before you publish a policy or compliance mapping that cites it.
The API2:2023 Broken Authentication page and the API10:2023 Unsafe Consumption of APIs page contain the full guidance quoted in this article.
Quick Recap
“
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
