iTechGuides 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
Backend developers secure APIs by combining transport protection, authentication, per-request authorization, server-side validation, resource limits, secure configuration, and ongoing monitoring. No single control—including HTTPS, an API key, or an API gateway—covers all of those risks. The details depend on the API style and deployment, but the core principle is consistent: enforce the rules on the server at the point where each request is handled.
What should API security protect against?
A useful starting point is the OWASP API Security Top 10 2023, which organizes API risks into ten categories. It is a threat taxonomy, not a ranking of how often attacks happen or a prediction of the likelihood of a breach.
- API1:2023 — Broken Object Level Authorization: a caller can access an object they are not permitted to use.
- API2:2023 — Broken Authentication: weaknesses in establishing or verifying caller identity.
- API3:2023 — Broken Object Property Level Authorization: unauthorized exposure or modification of particular object fields.
- API4:2023 — Unrestricted Resource Consumption: requests can consume excessive bandwidth, CPU, memory, storage, or paid downstream services.
- API5:2023 — Broken Function Level Authorization: a caller can invoke an operation, such as an administrative action, that should not be available to them.
- API6:2023 — Unrestricted Access to Sensitive Business Flows: automated use of a legitimate workflow can cause business harm.
- API7:2023 — Server Side Request Forgery: a service fetches a remote resource based on an unvalidated user-supplied URI.
- API8:2023 — Security Misconfiguration: insecure settings or exposed interfaces create openings.
- API9:2023 — Improper Inventory Management: undocumented or outdated hosts, versions, and endpoints remain available.
- API10:2023 — Unsafe Consumption of APIs: a service trusts or validates data from another API less carefully than it would direct user input.
The OWASP REST Security Cheat Sheet provides implementation guidance for REST APIs. NIST’s Guidelines for API Protection for Cloud-Native Systems – March 2026 Update, published March 13, 2026, frames API protection across development and runtime, with basic and advanced measures that can be adopted incrementally according to risk. NIST SP 800-228A, Guidelines for the Secure Deployment of RESTful Web APIs, is a separate initial public draft published May 18, 2026; it is a draft, not a final standard.
Recommended Free Tools
How do developers protect the connection and credentials?
For REST services, OWASP recommends exposing HTTPS endpoints. HTTPS protects credentials while they travel over the network and lets clients authenticate the service and check message integrity. It does not determine whether an authenticated caller is allowed to read a particular record or perform a particular operation.
#1 Best Overall
Do not put passwords, access tokens, or API keys in URLs. URLs may be captured in server logs. Place sensitive request data in headers or request bodies as appropriate for the HTTP method and API design, and avoid logging secrets.
How do authentication and authorization differ?
Authentication establishes who the caller is. Authorization determines which resources and operations that caller may access. A successful login or valid token is not permission to use every endpoint or record.
For each request, enforce authorization at the endpoint or service that performs the action. OWASP’s REST guidance recommends access control at every endpoint for non-public REST services. In modern service architectures, identity verification can be centralized in an identity provider while endpoints make local access-control decisions.
Rank #2
Check access to each object
Never assume an object identifier supplied by a client is safe just because the caller is authenticated. For example, if a request asks for order 8472, the backend should verify that the current user may access order 8472 before returning or changing it. OWASP API1:2023 describes this as object-level authorization. The OWASP API Security Project says: “Object level authorization checks should be considered in every function that accesses a data source using an ID from the user.”
Control fields and operations separately
Object-level permission does not automatically grant permission to every property on that object. Explicitly limit which fields a caller may read or change; this addresses the exposure and modification risks described by OWASP API3:2023. Separately, apply function-level checks to sensitive actions, such as administrative operations, as described by API5:2023.
API keys can help meter public API usage or provide a basic abuse-control signal. OWASP cautions that third-party keys can be relatively easy to compromise, so a key alone is not adequate access control for sensitive, critical, or high-value resources.
Rank #3
How should a backend validate requests and business workflows?
Treat client-provided values as untrusted, whether they came from a browser, mobile app, partner integration, or another service. Validate expected type, format, length, and range against the endpoint’s contract. Reject unexpected content, set request-size limits, use a safe parser, and check that the request content type is supported.
For REST APIs, OWASP identifies 413 for an oversized payload and 415 for an unsupported media type. These responses make the failure understandable without accepting data the endpoint is not designed to process.
Validation must also cover business state, not just input shape. A workflow might require a record to be created, validated, approved, and then finalized. If the backend accepts a direct call to the final step without checking the record’s current state and caller’s permission, a client can bypass the intended sequence. Model valid states and transitions on the server, and reject transitions that are not allowed; frontend sequencing is not an enforcement mechanism.
Rank #4
- API Security in Action
- Manning Publications
- ABIS BOOK
How can developers limit API abuse and resource consumption?
Set limits appropriate to each endpoint’s cost and purpose. Consider request frequency, payload size, page or result counts, concurrency, and expensive operations. A search endpoint, for example, may need different bounds from a lightweight status check. Resource controls should account for downstream services too, particularly when a request can trigger a paid operation.
OWASP API4:2023 covers excessive consumption of bandwidth, CPU, memory, storage, and paid services. API6:2023 addresses automated abuse of sensitive business flows, which can cause harm even when the underlying feature works as designed. Rate limiting is one control: OWASP’s REST guidance uses 429 Too Many Requests for a rate-limited request. There is no single request-per-minute threshold that suits every API; choose limits based on resource cost, user needs, abuse risk, and operational capacity.
Free tools Windows power users keep installed
One-click scans. No signup required.
Rate limits and API keys do not replace authorization checks on sensitive resources. Apply resource bounds and access-control decisions as separate safeguards.
Best Value
How should developers secure integrations, configuration, and API versions?
Validate remote destinations and responses
If a service fetches a URL provided by a caller, validate the destination before making the request to reduce server-side request forgery risk (OWASP API7:2023). Treat responses from third-party APIs as untrusted input too: validate their structure and values before using them in application logic, as recommended by API10:2023.
Track endpoints and protect management interfaces
Maintain an inventory of API hosts, endpoint versions, and management interfaces. Retired versions, debug endpoints, or undocumented hosts can remain reachable if nobody tracks them; this is the inventory risk described by API9:2023. Review deployment settings and exposed functionality for security misconfiguration (API8:2023). OWASP’s REST guidance recommends keeping management endpoints off the public internet where possible. If they must be internet-accessible, protect them with strong authentication and network restrictions.
What should APIs return and record when requests fail?
Use responses that describe the client-visible problem without revealing stack traces, internal implementation details, or sensitive system information. OWASP’s REST guidance maps common conditions to these status codes:
The Tool Desk
Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →401for missing or incorrect authentication.403when an authenticated caller lacks permission.405for an unsupported HTTP method.413for an oversized payload.415for an unsupported media type.429for rate limiting.
For security-relevant events, retain useful internal audit records while sanitizing logged input to reduce log-injection risk. Do not put secrets in logs, and do not expose implementation details in a 500 response.
What does CORS protect?
For APIs used by browsers, set allowed CORS origins as specifically as practical. Disable CORS headers if cross-origin browser calls are not expected. CORS governs browser cross-origin access; it is not a substitute for authenticating callers or checking their authorization on the server.
How should a team put API security into practice?
- Inventory the API: record hosts, versions, endpoints, and management interfaces, including those scheduled for retirement.
- Map risks to controls: use the OWASP API Security Top 10 2023 categories to identify relevant risks, then choose controls based on the API’s data, operations, and deployment context.
- Enforce identity and permissions: authenticate callers where required and check access to each object, property, and operation on the server.
- Validate requests and state: enforce input contracts, size limits, content types, and permitted workflow transitions server-side.
- Bound expensive behavior: apply suitable frequency, payload, result-count, and operation limits, including controls for costly downstream calls.
- Review runtime behavior: monitor security-relevant activity, review configuration, and update the inventory as endpoints and versions change.
These controls can be enforced at a gateway, in service endpoints, or at both layers. A gateway can provide shared controls, while endpoint-level decisions remain important for permissions that depend on a particular user, object, or operation. NIST’s 2026 guidance treats protection as a set of risk-based implementation choices across development and runtime rather than a single control that solves every API risk.
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.
