Do these 3 things before closing this tab:
1Repair Windows errors before they cause bigger problems2Scan for outdated or missing drivers - takes under a minute3Clear out junk files and repair common Windows errorsiTechGuides 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
Use the OWASP API Security Top 10 (2023) as an engineering program, not a checklist. The effective defense combines server-side authorization, strict request and response contracts, abuse limits, dependency controls, complete API inventory, telemetry, and repeatable tests. Authorization deserves first attention: OWASP’s 2023 project identifies it as the biggest challenge because a correctly authenticated caller can still access another user’s record or invoke an administrative action.
This guide maps each risk to concrete controls for REST, GraphQL, webhooks, and service-to-service APIs. It also gives an identity test matrix, an SSRF test method, a way to find undocumented endpoints, and an operating model that keeps protections effective as versions and integrations change.
What does the OWASP API Security Top 10 protect?
The list describes recurring ways an API can expose data, execute functions, consume resources, or be abused through legitimate business workflows. It is about application behavior, not only network vulnerabilities. A TLS certificate can be valid while an endpoint still lets one tenant read another tenant’s invoice.
OWASP’s 2023 update treats APIs as a dominant attack surface and places more emphasis on authorization, abuse of valid flows, and trust in upstream services. Each risk should have an owner, a written policy, automated tests, production signals, and a response procedure.
#1 Best Overall
What are the OWASP API Security Top 10 (2023) risks?
The categories below are the current reference set. Several overlap in symptoms, but each points to a different control family and test strategy.
| Risk | What fails | Primary defenses |
|---|---|---|
| API1:2023 Broken Object Level Authorization (BOLA) | A caller changes an object identifier and receives another user’s or tenant’s object. | Authorize the object after loading it; test cross-user and cross-tenant access. |
| API2:2023 Broken Authentication | Weak token, session, or identity validation permits impersonation. | One consistent authentication layer; validate signature, issuer, audience, expiry, and session state. |
| API3:2023 Broken Object Property Level Authorization | Responses expose fields a caller should not see, or requests let callers set server-controlled fields. | Response DTOs, request allowlists, and per-field authorization. |
| API4:2023 Unrestricted Resource Consumption | Requests exhaust bandwidth, CPU, memory, storage, concurrency, or paid downstream services. | Quotas, pagination, payload ceilings, timeouts, concurrency limits, and endpoint-specific rate limits. |
| API5:2023 Broken Function Level Authorization | A low-privilege or unauthenticated caller invokes an administrative or privileged function. | Server-side policy checks on every function and tests across role levels. |
| API6:2023 Unrestricted Access to Sensitive Business Flows | Automation scales a valid workflow into fraud or operational harm. | Business quotas, anti-automation friction, anomaly detection, and risk-based review. |
| API7:2023 Server-Side Request Forgery (SSRF) | A user-controlled URI makes the server contact internal or unintended destinations. | Destination allowlists, normalized parsing, redirect and DNS controls, egress filtering, and telemetry. |
| API8:2023 Security Misconfiguration | Defaults, debug routes, permissive CORS, verbose errors, weak TLS, or exposed secrets widen attack paths. | Hardened configuration, schema and header validation, secret management, and environment reviews. |
| API9:2023 Improper Inventory Management | Shadow, zombie, debug, or legacy endpoints remain reachable without ownership or controls. | Continuous inventory of hosts, routes, versions, schemas, owners, authentication, and retirement dates. |
| API10:2023 Unsafe Consumption of APIs | An upstream response or dependency is trusted without validation and becomes an attack path. | Schema validation, limits, isolation, dependency review, timeouts, and anomaly monitoring. |
How do I prevent BOLA or IDOR in a REST API?
Perform an object-level authorization decision on every operation that uses a caller-supplied identifier. Authentication answers who the caller is; BOLA protection answers whether that identity may act on this specific object in this specific tenant.
Authorize after retrieving by tenant
Prefer a data-access method that includes the principal’s tenant or user scope rather than fetching by a globally supplied ID and checking later. For example, a query should conceptually constrain both values:
SELECT * FROM invoices
WHERE id = :invoice_id AND tenant_id = :caller_tenant_id;
If the object is not returned, use the same externally safe response for “not found” and “not permitted” where revealing existence would matter. Apply the check to reads, updates, deletes, downloads, exports, and nested resources; do not assume that a protected parent route automatically protects every child operation.
Test with a deliberate identity matrix
Create objects for two users in two tenants. Call each endpoint as the owner, a same-tenant peer, a cross-tenant user, an administrator, a service account, and an anonymous caller. Replace identifiers in path, query, JSON, GraphQL variables, and batch requests. A passing test proves denial, not merely that an error was logged.
How do I secure JWT authentication and other API sessions?
Use one centrally maintained authentication layer and make every route—including old, obscure, and internal-looking routes—use it. A JWT should be accepted only after cryptographic and semantic validation, followed by any required server-side session or revocation check.
Validate every security-relevant claim
- Verify the signature with an approved algorithm and a trusted key set; do not select an algorithm from untrusted token content.
- Check the expected issuer and audience, plus expiration and not-before times with a small, defined clock-skew allowance.
- Enforce token type, scope, and required subject claims for the endpoint.
- Reject malformed, unsigned, expired, revoked, or replayed tokens according to your session policy.
- Rotate signing keys with an overlap period, publish key identifiers safely, and remove retired keys after all valid tokens expire.
Negative tests should include a token signed by the wrong key, a valid token for another audience, an expired token, a malformed token, a revoked session, and a token presented to a route that should require a stronger scope. Treat API keys, cookies, and service credentials with the same discipline: limited permissions, expiration or rotation, secure storage, and audit trails.
Recommended Free Tools
How do I stop mass assignment and excessive data exposure?
Separate the fields a client may submit from the fields your service stores and the fields it returns. Property-level authorization is the common root behind both mass assignment and excessive data exposure.
Rank #2
Use explicit request allowlists
Bind incoming JSON to a request type containing only editable fields. Ignore or reject fields such as role, tenant_id, is_verified, billing_status, and server timestamps unless a narrowly authorized administrative operation handles them. Reject unknown fields when practical so clients cannot silently rely on accidental behavior.
Use response DTOs
Do not serialize database models directly. Build a response representation for each audience and operation. A support agent, end user, and internal service may receive different fields from the same record. Authorize especially sensitive properties independently when a role can see the object but not every attribute.
Test both directions: request a forbidden field and confirm it is rejected or ignored, then inspect every response path—including errors, exports, search results, GraphQL fragments, and bulk endpoints—for fields outside the caller’s contract.
How should I rate-limit API endpoints and control resource consumption?
Rate limiting is necessary but insufficient. Protect the full resource budget—request size, response size, CPU time, memory, concurrent work, storage, and calls to paid services such as email, SMS, or verification providers.
Set limits by endpoint and identity
Use separate policies for anonymous traffic, authenticated users, tenants, IP ranges, and service accounts. Sign-in, sign-up, password-reset, verification, search, file processing, and report generation normally need stricter or more expensive limits than a simple read. Return a consistent throttling response and document retry behavior; use a server-controlled delay rather than allowing clients to create synchronization storms.
Bound expensive operations
- Require bounded page sizes and reject extreme offsets; prefer cursor pagination for large collections.
- Set maximum JSON, multipart, GraphQL query, and file sizes before parsing into memory.
- Cap filter complexity, sort fields, recursion depth, and query cost.
- Use queue limits, worker concurrency caps, deadlines, and cancellation for long tasks.
- Apply circuit breakers and per-operation budgets to downstream calls.
Load tests should script large payloads, deep pagination, expensive filters, concurrent requests, and repeated verification calls. A passive vulnerability scanner will not demonstrate these failure modes.
How do I protect sensitive business flows from automation?
API6 concerns valid actions that become harmful when automated at scale. Examples include ticket purchases, bulk buying, commenting, promotional redemption, and account creation. Authentication alone does not make these workflows safe.
Quick wins for a faster PC:
Repair Windows errors before they cause bigger problemsFix Now →Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Clear out junk files and repair common Windows errorsFree Scan →Attach limits to the business rule
Define limits such as purchases per account, device, payment instrument, address, or time window. Make the decision on the server and keep counters in a reliable, race-safe store. For scarce inventory, reserve and release stock atomically so parallel requests cannot oversell it.
Add proportional friction and detection
Use proof-of-work, challenge steps, queueing, device or reputation signals, manual review, or step-up authentication where the loss justifies the friction. Monitor velocity, unusual account creation, repeated failures, synchronized clients, and rapid changes in payment or delivery details. Avoid relying on a single IP address because distributed automation can rotate addresses.
How do I test and block SSRF in a webhook or URL-fetching feature?
Assume every user-supplied URL is hostile. The safest design is to avoid arbitrary fetching and accept only destinations that an administrator has explicitly registered.
Constrain destination resolution
- Parse and normalize the URL with a standards-compliant library; reject ambiguous schemes, credentials, fragments used to disguise hosts, and unexpected ports.
- Resolve DNS and evaluate every resulting address against an allowlist. Block loopback, link-local, private, carrier-grade NAT, multicast, and other internal ranges appropriate to your network.
- Re-check the destination after redirects and after DNS resolution to reduce rebinding opportunities.
- Use an egress proxy or firewall policy that denies internal networks and cloud metadata services even if application validation fails.
- Set connection, response, redirect-count, and body-size limits. Do not stream unlimited responses into memory.
- Record the requested host, resolved address, decision, latency, status, and failure reason without logging secrets.
Run safe SSRF tests
Use a controlled callback endpoint to confirm that an approved request leaves the service. Then test blocked internal-address cases, alternate numeric and encoded address forms, redirects to blocked destinations, DNS changes between validation and connection, and unsupported schemes. The test environment should contain no production credentials or sensitive metadata.
The Tool Desk
Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →How do I find shadow, zombie, and deprecated APIs?
Maintain an inventory that is continuously reconciled with deployed behavior. A document updated once a year cannot detect a temporary debug route or a forgotten version.
Build the inventory record
For every host and route, record protocol, version, schema, owner, data classification, authentication requirement, authorization policy, environment, dependencies, deployment source, and deprecation date. Include REST paths and methods, GraphQL operations, webhooks, event consumers, administrative interfaces, and machine-to-machine routes.
Compare multiple evidence sources
- Collect OpenAPI and GraphQL schemas from source repositories and deployment pipelines.
- Observe gateway, load-balancer, application, and service-mesh logs to discover routes actually called.
- Enumerate DNS names, certificates, ingress rules, and container or function deployments.
- Compare observed methods, fields, headers, and status codes with the declared contract.
- Flag routes with no owner, no authentication, an expired version, or no recent deployment reference.
Retire an endpoint by announcing a date, measuring remaining callers, denying new clients, and finally removing the route or placing it behind an explicit migration control. Keep a record of exceptions so emergency access does not become permanent.
How do I secure third-party API integrations?
Treat every upstream response as untrusted input, even when the provider is reputable. An attacker may target an integrated service to reach your parser, business logic, queue, or secrets.
Validate and isolate responses
Check content type, schema, required fields, numeric ranges, encoding, and maximum size before using a response. Reject contradictory or unauthorized states rather than “repairing” them silently. Run parsers with least privilege, isolate integration workers, and prevent an upstream payload from selecting arbitrary files, commands, URLs, or database operations.
Rank #4
Control dependency and failure behavior
Pin or review dependency changes, monitor advisories, and define an owner for each integration. Apply connect and read timeouts, bounded retries with jitter, circuit breakers, and idempotency keys. Record provider latency, status distributions, validation failures, and anomalous content so an outage or compromise is visible without exposing personal data.
What is a practical API security testing workflow?
Run security tests throughout design, delivery, and production. No single scanner can prove authorization, business-flow safety, or resilience to resource exhaustion.
- Reconnaissance and contract review: collect OpenAPI or GraphQL schemas, enumerate hosts and versions, and identify undocumented routes. OWASP’s Web Security Testing Guide treats API reconnaissance as a dedicated testing area.
- Identity matrix: execute each endpoint as anonymous, ordinary user, same-tenant peer, cross-tenant user, administrator, service account, expired token, malformed token, and revoked token.
- Object and property checks: substitute identifiers, alter tenant references, add server-controlled fields, request sensitive properties, and compare output to the caller’s permissions.
- Schema and protocol checks: validate request and response bodies, content types, headers, GraphQL query paths, depth, and complexity.
- Abuse and load checks: exercise pagination extremes, large payloads, concurrent calls, expensive filters, repeated verification, and automated sensitive flows.
- SSRF checks: use controlled callbacks and safe internal-address cases to test parsing, redirects, DNS rebinding defenses, and egress controls.
- Integration fault injection: send malformed, oversized, delayed, contradictory, and unauthorized upstream responses; verify validation, timeouts, circuit breakers, and logs.
- Operational checks: review secrets, defaults, error detail, CORS, TLS, debug routes, version retirement, and alert coverage in CI and production.
Turn every failed test into a regression case. A release should fail when a policy check disappears, a new route lacks an owner, or a contract expands without an authorization decision.
Crashes, 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 minutePC 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 & 11How should teams assign ownership and telemetry?
Security controls fail when responsibility is ambiguous. Assign an owner for each API, data domain, authorization policy, dependency, and deprecation decision. The platform team can provide shared authentication, rate-limit middleware, schema tooling, and egress policy, but the service team must define who may perform each business action and see each field.
Log decisions rather than secrets: principal or service identity, tenant, route, object classification, authorization result, policy version, request correlation ID, rate-limit outcome, upstream status, and latency. Protect logs with access controls and retention limits. Alert on repeated cross-tenant denials, token failures, sudden route discovery, unusual resource consumption, SSRF blocks, and validation failures from an upstream provider.
What changed between the 2019 and 2023 OWASP API lists?
The 2023 project combined excessive data exposure and mass assignment into API3, Broken Object Property Level Authorization, because both stem from missing field-level decisions. It gave resource consumption greater emphasis, added unrestricted access to sensitive business flows, and added SSRF as its own category. The update also stresses that authorization remains the dominant challenge, so identity verification must be paired with object, property, and function policy.
Which defenses should a modern backend prioritize first?
Start with authorization because one missing check can expose an entire tenant or administrative surface. In the same delivery cycle, establish a complete inventory and a common authentication layer; otherwise tests and fixes will miss routes. Next enforce request and response schemas, resource budgets, and egress restrictions. Finally add business-flow detection, upstream isolation, and production telemetry so abuse that passes ordinary authentication becomes visible and containable.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Use the OWASP API Security Top 10 as a continuing engineering baseline rather than a one-time audit. A useful companion for implementation teams is Secure APIs: Design, build, and implement by José Haro Peralta, a 376-page Manning trade paperback published in November 2025 (ISBN 9781633436633), which covers secure design, the OWASP Top 10, zero trust, automated testing, observability, and incident response.
Frequently asked questions
Should I use opaque tokens instead of JWTs?
Neither format is automatically safer. Opaque tokens make server-side revocation and session state straightforward, while JWTs can reduce lookup overhead but require careful key, claim, audience, and lifetime management. Choose based on revocation needs, service topology, and operational ability to rotate keys and monitor use.
Do API gateways replace authorization in application code?
No. A gateway can authenticate requests, apply coarse quotas, and block known destinations, but it usually cannot decide whether a caller may access a particular object or field. The service that owns the data must enforce object, property, and function policy.
How often should an API inventory be reconciled?
Reconcile it on every deployment and continuously from runtime traffic, then perform a scheduled review for routes with no owner or retirement date. The correct interval depends on deployment frequency and risk; high-change services should not wait for a quarterly audit.
What should I do when a legitimate client is blocked by a new limit?
Identify the client by authenticated identity and endpoint behavior, not by silently widening a global limit. Provide a documented quota or service tier, require the client to use pagination or batching safely, and record a time-bounded exception with an owner and review date.
Can GraphQL avoid the OWASP API risks that affect REST?
No. GraphQL changes the request shape but not the underlying authorization and resource risks. Apply field and resolver authorization, query-depth and complexity limits, response-size ceilings, introspection policy, and the same identity and abuse tests used for REST.
Frequently Asked Questions
Should I use opaque tokens instead of JWTs?
Neither format is automatically safer. Opaque tokens simplify server-side revocation, while JWTs can reduce lookups but require disciplined key rotation, claim validation, and lifetime management. Choose according to your revocation needs and operational maturity.
Do API gateways replace authorization in application code?
No. Gateways provide useful authentication, quotas, and coarse filtering, but the data-owning service must decide whether a caller may access a particular object, field, or business function.
Free tools Windows power users keep installed
One-click scans. No signup required.
How often should an API inventory be reconciled?
Reconcile it at every deployment and continuously from runtime traffic, with scheduled ownership and retirement reviews. Fast-changing services should not rely on quarterly or annual discovery.
What should I do when a legitimate client is blocked by a new limit?
Identify the client and endpoint behavior, then provide a documented quota or safer batching and pagination guidance. Any exception should be time-bounded, owned, monitored, and reviewed rather than becoming a permanent global limit increase.
Can GraphQL avoid the OWASP API risks that affect REST?
No. GraphQL still needs resolver and field authorization, query-depth and complexity limits, response-size ceilings, and abuse testing. The protocol changes request syntax, not the underlying security decisions.
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.
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 →

