OpenAPI

The OpenAPI Specification (OAS, formerly Swagger) is a standardized, language-agnostic format for describing RESTful APIs. An OpenAPI document, written in YAML or JSON, defines every endpoint, request and response format, parameter, data type, and authentication method an API supports, in a machine-readable way.

What teams use OpenAPI for

• Design and documentation. The spec is a blueprint of the API’s structure and behavior. It’s invaluable during design and becomes the canonical reference afterward. Interactive docs (Swagger UI, Redoc, and friends) render directly from it.
• Code generation. Tools like OpenAPI Generator produce client SDKs, server stubs, and documentation in dozens of languages, letting developers focus on business logic instead of boilerplate.
• Testing and mocking. Contract tests and mock servers can be driven straight from the document.

The common thread: the OpenAPI document is the single source of truth for what the API accepts and returns.

How OAShield uses OpenAPI

OAShield extends that source of truth to your security perimeter. It’s built on OpenAPI Generator itself, but instead of generating a client or server, it generates WAF rules that permit only the traffic your spec defines:

• Declared endpoints and methods are allowed; everything else is denied.
• Parameter types, formats, enums, patterns, and numeric bounds from your schemas become validation rules.
• Required parameters and body fields are enforced; undeclared ones are blocked.

For instance, if the API doesn’t define a POST method for a particular endpoint, OAShield generates rules that block any POST request to it. The better your spec, the tighter your perimeter: precise types, patterns, and enums translate directly into stricter validation. See How It Works for the full mechanics.