API Security Policy Template: Standards Every Internal and Public API Must Meet

Most organisations publish more APIs than they can name, and without a policy each team decides for itself whether an endpoint needs authentication, an owner, a rate limit or a retirement date. This template gives you an API security policy with numbered statements you can adopt as written: inventory and ownership, authentication of users and machines, authorisation, rate and resource limits, logging, testing and deprecation. It applies to internal, partner and public APIs that [Organisation] builds or operates, and to the third-party APIs it consumes, and it is mapped to ISO/IEC 27001:2022 Annex A, NIST CSF 2.0 and the OWASP API Security Top 10 2023. It is written for CISOs, API platform owners, application security leads and GRC teams. The API Security Guide explains the discipline; this page is the policy document, and the API Security Checklist is how teams prove they meet it.

How to use this template

• Replace text in square brackets, such as [Organisation], [API platform team] and [X days], with your own terms and values. Values in brackets are illustrative starting points, not requirements from any standard.
• "Must" indicates a mandatory requirement; "should" indicates a recommended practice where a justified exception may apply under section 5.
• Keep product configuration (gateway policies, identity provider settings, scanner rules) in a supporting API security standard owned by [API platform team]. The policy states what must be true; the standard states how.
• Statements about callers apply equally to human users, workloads, partner systems and AI agents that call [Organisation] APIs.

1. Purpose

This policy sets the minimum security requirements for designing, building, deploying, operating, consuming and retiring application programming interfaces (APIs) at [Organisation], so that every API is known and owned, every caller is authenticated and limited to what it is permitted to do, abuse is detected quickly, and no API outlives its support.

2. Scope

This policy applies to:

• APIs provided: all REST, GraphQL, gRPC, SOAP, WebSocket and event or webhook interfaces built, hosted or operated by or for [Organisation], in every environment, whether public, partner-facing or internal.
• APIs consumed: third-party and SaaS APIs that [Organisation] systems call or that send data into them.
• API credentials: API keys, OAuth clients and tokens, client certificates, webhook secrets and workload identities used to call or protect APIs.
• People: employees, contractors and suppliers who design, build, operate or approve APIs.

Internal-only network location does not exempt an API from this policy.

3. Roles and responsibilities

4. Policy statements

4.1 Inventory and ownership

1. Every API must be registered in [API inventory] before it receives production traffic, with: named owner, purpose, environment, audience (public, partner, internal), version, data classification, authentication method and the hosts it is served from.
2. Every API must have a machine-readable specification (OpenAPI, GraphQL schema or protobuf definition) held in version control and kept consistent with the deployed API.
3. API documentation must be available only to those authorised to use the API, except for APIs intended for public developers.
4. [API platform team] must reconcile the inventory against gateway, load balancer and DNS data at least [monthly]; any API found serving traffic without registration must be registered within [10] business days or blocked.
5. APIs whose owner leaves must be transferred to a new owner within [10] business days or scheduled for retirement.

4.2 Design and development

1. APIs that handle data classified [Confidential] or above, or that are exposed publicly or to partners, must have a documented threat model reviewed by [Application security team] before first release and after significant change.
2. API owners must document authorisation rules for every operation and data item, including field-level read and write restrictions.
3. API owners must identify sensitive business flows (for example account creation, purchase, payment, password reset, OTP validation) and define abuse limits for each.
4. Responses must return only the properties the caller is permitted to see; generic serialisation of internal objects is prohibited.
5. Requests must be validated against the specification, including data types, sizes, ranges and allowed content types; unknown properties must be rejected or ignored, never bound automatically to internal objects.
6. Features that fetch resources from client-supplied URLs must use allow lists of destinations, schemes and ports, and must not reach internal address ranges or cloud metadata services.

4.3 Authentication

1. Every API operation must require authentication, except operations explicitly approved as public in [API inventory].
2. User-context access must use OAuth 2.0 or OpenID Connect via [authorisation server]; APIs must not accept user passwords directly, and the resource owner password credentials grant must not be used.
3. API keys may identify a client application but must not be used to authenticate a user.
4. Service-to-service and partner access must use a credential unique to each calling workload or partner: workload identity, mutual TLS or signed client assertions (private_key_jwt) are preferred over shared secrets.
5. APIs must validate every token on every request: signature against an allow list of algorithms, issuer, audience, expiry and token type. Tokens issued for another API must be rejected.
6. Access tokens should have a lifetime of no more than [60 minutes]. APIs handling [Restricted] data or payments should require sender-constrained tokens (mutual TLS or DPoP).
7. Authentication, credential recovery and OTP endpoints must have brute-force protection stricter than general rate limits, and changes to account security attributes must require re-authentication.

4.4 Authorisation

1. Access must be denied by default; every function and data item requires an explicit grant.
2. Every operation that accepts an object identifier from the client must check that the caller is permitted to act on that specific object. Unpredictable identifiers do not replace this check.
3. Administrative functions must be enforced through a central authorisation mechanism, not by obscurity of the endpoint path.
4. OAuth scopes and roles must be the minimum each client needs and must be reviewed at least [annually] by the API owner.
5. Automated tests demonstrating that one user or tenant cannot access another's objects, and that non-privileged callers cannot invoke privileged functions, must run in the build pipeline for APIs in scope of 4.2.1.

4.5 API credentials

1. API credentials must be stored in [approved secrets manager] or issued by a workload identity platform, and must never be placed in source code, container images, client-side code, tickets or chat.
2. Each API credential must have a named owner, a documented purpose and scope, and an expiry or rotation interval of no more than [90 days] for static secrets.
3. Credentials must be revoked within [24 hours] of suspected exposure, and within [10] business days of the owning integration being retired.
4. Webhook receivers must verify a signature or shared secret on every message and reject replayed messages.

4.6 Transport, configuration and rate limits

1. All API traffic, internal and external, must use TLS 1.2 or higher. Non-browser endpoints must refuse plain HTTP rather than redirect.
2. Public and partner APIs must be published through [API gateway], which must enforce authentication, schema validation and rate limits.
3. Rate limits must be set per client and per operation; maximum page sizes and payload sizes must be enforced server side. Exceeding a limit must return HTTP 429.
4. Only the HTTP methods each route needs may be enabled. Browser-facing APIs must define an explicit CORS allow list.
5. Error responses must not disclose stack traces, internal hostnames or software versions.
6. GraphQL APIs must enforce query depth or cost limits, and introspection must be disabled in production unless the API is intended for external developers.
7. Spending limits or billing alerts must be configured for paid downstream APIs that callers can trigger.
8. Non-production APIs must not use production data unless they receive the same controls as production.

4.7 Logging and monitoring

1. APIs must log authentication successes and failures, authorisation failures, rate-limit events and administrative actions, with caller identity, client ID, source address, operation and timestamp, in line with the [Logging and Monitoring Policy].
2. Logs must not contain full tokens, API keys, passwords or personal data beyond what the [Logging and Monitoring Policy] permits.
3. Logs for APIs in scope of 4.2.1 must reach [SIEM] within [5 minutes] and be retained for at least [12 months].
4. [Security operations] must maintain alerts for: repeated authorisation failures from one client, sequential object enumeration, record volumes above baseline per client, and traffic to unregistered API hosts.

4.8 Testing

1. APIs in scope of 4.2.1 must undergo authenticated security testing covering object-level and function-level authorisation before first release and after major changes.
2. Public and partner APIs must have an independent penetration test at least every [12 months].
3. Findings must be fixed within the timescales in the [Vulnerability Management Policy].

4.9 Versioning, deprecation and retirement

1. Every API version must have a published support end date. No more than [two] major versions of an API should be live at once.
2. Deprecated versions must keep the same gateway, authentication and monitoring controls as the current version until removed.
3. When a new version fixes a security weakness, the API owner must record within [30 days] whether the fix is backported or older versions are withdrawn, and by what date.
4. Consumers must be notified at least [90 days] before retirement, except where an urgent security risk requires faster removal.
5. On retirement, routes must be removed from the gateway, DNS records and credentials deleted, and the inventory updated.

4.10 Consuming third-party APIs

1. Third-party API providers that receive or return [Confidential] data must be assessed under the [Supplier Security Policy] before integration.
2. Data received from third-party APIs must be validated before use; redirects must be followed only to allow-listed locations.
3. Credentials for third-party APIs must follow section 4.5 and be scoped to the minimum permissions the provider offers.

5. Exceptions

1. Exceptions must be requested through [GRC tool] by the API owner, stating the requirement, the reason, compensating controls and an end date no more than [12 months] away.
2. Exceptions for public or partner APIs, or for [Restricted] data, must be approved by [CISO]; others by [Head of Application Security].
3. Expired exceptions are treated as non-compliance.

6. Compliance and monitoring

[Application security team] will verify compliance using the API Security Checklist, gateway configuration, inventory reconciliation and test reports, and will report these measures to [Risk committee] [quarterly]:

• Percentage of APIs in production registered with a named owner and specification (target 100 percent).
• Number of unregistered API hosts found, and median days to register or block them.
• Percentage of public and partner APIs tested in the last 12 months.
• Open high and critical API findings past due.
• Percentage of API credentials with an owner and expiry date.

Breaches of this policy may lead to an API being blocked at the gateway and to action under [disciplinary or supplier procedures].

7. Review and approval

This policy is reviewed at least annually and after any significant API-related incident by [CISO]. Version [1.0], approved by [name, role] on [date]. Next review: [date].

Implementation guidance

1. Inventory first, then enforce. Statements 4.1.1 and 4.1.4 make every other section enforceable. Publish the policy with a [90-day] registration window, then switch the gateway to block unregistered routes.
2. Write the standard alongside. Translate 4.3 and 4.6 into gateway policy and identity provider configuration so compliance is the default path for developers, not paperwork.
3. Phase by risk. Apply the full policy to public and partner APIs handling [Confidential] data first, then internal APIs. Small organisations with a few APIs can adopt it in one step; large estates should tier APIs and allow teams to show progress through the checklist.
4. Roll out limits safely. Introduce new rate limits and schema enforcement in monitor mode, review the would-be blocks with API owners, then enforce, keeping the prior gateway configuration versioned for rollback.
5. Use incidents as evidence. The T-Mobile API Breach 2023, where an API returned data on around 37 million accounts for about six weeks before detection, maps directly to statements 4.1, 4.4.2 and 4.7.4. See the Rate Limiting and API Abuse Guide for setting abuse thresholds.

Framework mapping

For NIST SP 800-53 users, the closest controls are CM-8 (inventory), IA-9 (service identification and authentication), AC-3 and AC-6 (authorisation), SC-8 (transmission protection), SC-5 (denial-of-service protection), SI-10 (input validation), AU-2 (event logging) and SA-11 (developer testing).

Standards and references

• OWASP: API Security Top 10 2023
• OWASP: Application Security Verification Standard 5.0
• ISO: ISO/IEC 27001:2022 Information security management systems
• NIST: Cybersecurity Framework 2.0
• NIST: SP 800-53 Rev. 5 Security and Privacy Controls
• NIST: SP 800-228, Guidelines for API Protection for Cloud-Native Systems
• IETF: RFC 9700, Best Current Practice for OAuth 2.0 Security
• IETF: RFC 8725, JSON Web Token Best Current Practices

This template is provided for guidance and must be adapted to your organisation. It is not legal advice. Related NHI Mgmt Group resources: API Security Guide · API Security Checklist · Application Security Policy Template · API Key Management Guide · Machine-to-Machine OAuth (Client Credentials) Guide