diff --git a/blog/enforcing-api-security-policies.md b/blog/enforcing-api-security-policies.md
new file mode 100644
index 00000000..32fcefb5
--- /dev/null
+++ b/blog/enforcing-api-security-policies.md
@@ -0,0 +1,155 @@
+---
+template: '../@theme/templates/BlogPost'
+title: Enforcing API security policies
+description: Securing an API ecosystem requires more than just placing a gateway in front of your services. Effective API security policies must operate as a continuous contract, codified during design and enforced through deployment and runtime access.
+seo:
+  title: Enforcing API security policies | Redocly
+  description: Learn how to implement API security policies across design-time and runtime enforcement, covering authentication, authorization, traffic management, and data governance.
+author: adam-altman
+publishedDate: 2026-02-20
+categories:
+  - api-governance
+  - api-lifecycle
+  - api-specifications
+---
+
+Securing an API ecosystem requires more than just placing a gateway in front of your services. While runtime enforcement is necessary, it often catches security issues too late in the process. Effective API security policies must operate as a continuous contract, codified during design and enforced through deployment and runtime access. If a policy exists only in a PDF document and not in your CI/CD pipeline or gateway configuration, it is essentially a suggestion, not a control.
+
+TL;DR
+
+* Runtime gateways handle immediate threats like DDoS, but design-time linting catches architectural flaws before deployment.
+* Authorization policies must distinguish between coarse-grained access (gateway) and fine-grained object access (application logic).
+* Inventory governance is a security function. Undocumented "shadow" endpoints bypass even the strongest authentication rules.
+* Rate limiting requires business context to protect sensitive flows, as generic volume caps often fail to stop low-and-slow abuse.
+
+## The two planes of policy enforcement
+
+A common misconception is that API security policies live solely in the API gateway or Web Application Firewall (WAF). While these tools provide critical runtime protection, relying on them exclusively creates a reactive security posture. The need for a multi-layered approach is driven by the sheer volume of threats. Akamai research has highlighted that [APIs are now primary targets](https://www.akamai.com/newsroom/press-release/akamai-research-web-attacks-up-33-apis-emerge-as-primary-targets) for abuse, with attacks extending beyond technical exploits into business logic manipulation. Relying on a single checkpoint is no longer sufficient to handle this scale of hostility.
+
+A comprehensive security strategy enforces policies on two distinct planes to mitigate these risks effectively.
+
+Design-time enforcement (Shift Left) focuses on the API definition itself. This involves using tools to lint OpenAPI descriptions against security [rulesets](https://redocly.com/docs/cli/rules). For example, a policy might dictate that every endpoint must define a security scheme or that specific PII patterns cannot appear in URL parameters. Validating the spec catches vulnerabilities before code is even written.
+
+Runtime enforcement (Shield Right) occurs when traffic hits the network. This includes the gateway verifying tokens, the application checking object-level permissions, and monitors watching for anomalous behavior.
+
+[NIST Special Publication 800-228](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-228.pdf) distinguishes explicitly between these "pre-runtime" and "runtime" protections. Organizations that successfully secure their APIs treat the [OpenAPI description as a security contract](https://redocly.com/learn/security), ensuring that what is defined in the spec matches what is enforced in the gateway.
+
+## Authentication and identity policies
+
+Authentication policies define how you verify the identity of a client. In modern API architectures, simply checking for an API key is rarely sufficient for accessing sensitive user data.
+
+### Differentiating API keys and user identity
+
+A frequent pitfall is treating API keys as user authentication. [OWASP API Security Risk #2 (Broken Authentication)](https://owasp.org/API-Security/editions/2023/en/0xa2-broken-authentication/) highlights that API keys identify the project or client application, not the user.
+
+Your policies should strictly separate these concepts. Use API keys for throttling, metering, and identifying the calling application. Use standard protocols like OAuth 2.0 or OpenID Connect (OIDC) to authenticate the actual user. This separation ensures that if a user leaves an organization, their access is revoked via the Identity Provider (IdP) without needing to rotate the API keys used by the application itself.
+
+### Enforcing modern token standards
+
+Policy enforcement for tokens has evolved. The IETF's recent "[Best Current Practice for OAuth 2.0 Security](https://www.ietf.org/rfc/rfc9700.html)" (RFC 9700) and related standards recommend moving away from implicit flows and bearer tokens in high-security contexts.
+
+Draft policies that enforce "sender-constrained" tokens where possible. Mechanisms like [DPoP (Demonstrating Proof-of-Possession)](https://www.rfc-editor.org/rfc/rfc9449) or [mTLS (Mutual TLS)](https://www.rfc-editor.org/rfc/rfc8705) bind a token to the specific client certificate or private key that requested it. If a bearer token is stolen, an attacker can use it anywhere. If a sender-constrained token is stolen, it is useless without the underlying cryptographic proof.
+
+## Authorization and access control
+
+Authentication verifies who the user is; authorization verifies what they can do. This continues to be a major failure point in API security, consistently topping the OWASP API Security list as [Broken Object Level Authorization (BOLA)](https://owasp.org/API-Security/editions/2023/en/0xa1-broken-object-level-authorization/).
+
+### The limits of gateway enforcement
+
+API gateways are excellent at coarse-grained authorization. They can easily enforce a policy where "only users with the `premium` scope can access `GET /analytics`."
+
+However, gateways rarely have the context to enforce fine-grained, object-level policies. A gateway generally cannot determine if User A is allowed to view Document 123. That logic relies on the relationship between the user and the data, which lives inside the application database.
+
+Your security policy must explicitly delegate object-level checks to the business logic layer. Relying on the gateway to handle all authorization often leads to BOLA vulnerabilities where a legitimate user can access another user's resources simply by changing an ID in the URL.
+
+### Preventing function-level bypass
+
+[Broken Function Level Authorization (BFLA)](https://owasp.org/API-Security/editions/2023/en/0xa5-broken-function-level-authorization/) occurs when administrative endpoints are exposed to non-administrative users. This often happens when developers rely on obscurity (assuming that because a user doesn't see a "Delete" button in the UI, they won't call the `DELETE` API endpoint).
+
+Enforce a default-deny policy at the gateway level. Unless an endpoint is explicitly defined in the [OpenAPI specification](https://redocly.com/docs/cli/api-standards) and authorized for a specific role, the gateway should reject the traffic. This prevents "shadow" administrative functions from being discovered and exploited.
+
+## Traffic management and abuse prevention
+
+Availability is a security metric. If an attacker can exhaust your API's resources, they have successfully compromised the service. Traffic policies must go beyond simple counters.
+
+### Context-aware rate limiting
+
+A global rate limit (e.g., 1000 requests per minute) is too blunt for security purposes. It might stop a volumetric DDoS attack but will fail to stop "low and slow" attacks, such as credential stuffing or inventory scraping.
+
+[OWASP API4 (Unrestricted Resource Consumption)](https://owasp.org/API-Security/editions/2023/en/0xa4-unrestricted-resource-consumption/) and [API6 (Unrestricted Access to Sensitive Business Flows)](https://owasp.org/API-Security/editions/2023/en/0xa6-unrestricted-access-to-sensitive-business-flows/) suggest categorizing endpoints by sensitivity. A login endpoint, a "checkout" endpoint, or a search endpoint requires much stricter, granular throttling than a static "get product list" endpoint.
+
+Effective policies apply friction based on the flow. For sensitive business flows, integrate step-up authentication or CAPTCHAs when usage patterns deviate from the norm, instead of just blocking the IP.
+
+### Quotas and payload constraints
+
+Resource exhaustion also comes from processing large datasets. Security policies should enforce strict limits on request sizes.
+
+* Define maximum payload sizes for `POST` and `PUT` bodies.
+* Enforce pagination on all list endpoints to preventing clients from requesting full database dumps.
+* Set timeout limits on backend processing to prevent query floods from locking up database connections.
+
+## Data governance and schema validation
+
+Data policies ensure that the API only accepts valid input and only returns allowed output.
+
+### Strict schema enforcement
+
+Input validation is the primary defense against injection attacks. Policies should reject any request that does not strictly conform to the defined schema. Validation includes checking data types, string patterns, and value ranges.
+
+You can automate this by using the OpenAPI definition as the validation engine. Gateways and application frameworks can ingest the spec and automatically reject requests that contain undefined parameters. This reduces the attack surface by eliminating the possibility of "mass assignment," where an attacker injects fields like `is_admin: true` into a request.
+
+### Preventing data leakage
+
+Excessive Data Exposure, categorized as [Broken Object Property Level Authorization](https://owasp.org/API-Security/editions/2023/en/0xa3-broken-object-property-level-authorization/) in OWASP 2023, happens when an API returns a full data object (including PII or internal flags) and relies on the frontend client to filter what the user sees.
+
+Enforce response validation policies that strip undefined fields from the response before it leaves the network boundary. If the [security schema defined](https://redocly.com/docs/cli/rules/oas/security-defined) in your API contract says the response contains three fields, the runtime response should never contain four.
+
+## Inventory and lifecycle governance
+
+You cannot secure an API you do not know about. "Zombie" APIs (old versions that were never decommissioned) are frequently targeted because they often lack the security patches applied to newer versions.
+
+### Deprecation policies
+
+Security policies must define a clear lifecycle for API versions. When a new version is released, the clock starts ticking on the old one.
+
+* Enforce sunset headers to warn consumers of upcoming deprecation.
+* Hard-stop dates must be enforced at the gateway.
+* Sandbox environments must be isolated from production data to prevent leaks during testing phases.
+
+### Assessing shadow APIs
+
+Inventory governance requires active discovery. Periodic scans of the network should compare running services against the registry of known, managed APIs. Any discrepancy represents a prompt risk that must be brought under management or shut down.
+
+## Operationalizing policies with CI/CD
+
+The most effective way to enforce API security policies is to move them upstream into the development pipeline. Policies should be applied every time code is committed, instead of waiting for a security review or penetration test.
+
+Pipeline enforcement ensures consistency. If a developer attempts to add an endpoint without a defined security scheme, the build should fail. If a change introduces a breaking change to the security contract, the merge request should be blocked.
+
+Automated enforcement transforms security from a gatekeeper into a guardrail. Developers receive immediate feedback on policy violations, allowing them to fix issues in the design phase where remediation is cheapest and easiest.
+
+## Integrating security into the API lifecycle
+
+API security is not a single setting; it is a continuity of validation that spans strict design contracts, testing pipelines, and runtime controls. By layering policies across these stages, organizations move from reacting to incidents to preventing architectural vulnerabilities. Redocly facilitates this approach by treating the API definition as the source of truth for security governance. By enforcing [configurable rules](https://redocly.com/docs/cli/guides/configure-rules) and standards during the design and build phases, teams ensure that the APIs deploying to production already adhere to the organization's security posture. This design-first governance ensures that gateways and runtime tools are enforcing a valid, secure contract rather than patching a leaky implementation.
+
+## FAQs about API security policies
+
+### What is the difference between an API gateway and an API security policy?
+
+An API gateway is the infrastructure or tool that processes traffic. An API security policy is the rule logic that the gateway enforces. For example, the policy might be "all calls require a valid OAuth token," while the gateway is the software that actually checks the header and blocks requests that violate that policy.
+
+### How do I enforce security policies on legacy APIs?
+
+Start by inventorying legacy endpoints and bringing them behind a gateway. Even if you cannot rewrite the application code immediately, you can apply "virtual patching" at the gateway level, enforcing rate limits, authentication, and basic schema validation externally to protect the vulnerable underlying service.
+
+### Can linting tools prevent runtime attacks?
+
+Linting cannot stop a runtime attack like a DDoS in progress, but it prevents the vulnerabilities that attackers exploit. Linting ensures that endpoints aren't deployed without authentication, that input schemas effectively block invalid data, and that sensitive data isn't exposed in URLs, significantly reducing the API's attack surface.
+
+### How often should API security policies be updated?
+
+Policies should be reviewed continuously, especially when new threat vectors emerge (like the shift to AI-driven scraping) or when industry standards update (such as new OAuth recommendations). Automated policy checks in CI/CD ensure that every code change is evaluated against the current standards.
+
+### What is the best way to handle API versioning for security?
+
+Use a [versioning strategy](https://redocly.com/blog/api-versioning-best-practices) that creates a predictable deprecation path. Security patches should ideally be backported to supported versions, but unsupported versions must be aggressively retired. Leaving old versions active indefinitely expands the attack surface.
\ No newline at end of file