How ApyGuard Uses OpenAPI to Power Intelligent API Security Testing
Learn how ApyGuard leverages OpenAPI specifications to build smarter, more accurate API security testing

At ApyGuard, we’re on a mission to make API security testing smarter, faster, and more automated. One of the key ways we achieve that is by leveraging OpenAPI specifications. Rather than relying on guesswork or static rules, ApyGuard dynamically reads your API's OpenAPI spec to understand exactly how your API is structured — and then builds valid, comprehensive test cases from that knowledge.
Here’s a look under the hood at how ApyGuard uses OpenAPI to supercharge your API security scans.
🔍 What We Import from OpenAPI
When you provide an OpenAPI spec to ApyGuard, we parse and import a wide range of details, including:
- Endpoints: Every API route and its associated HTTP method (GET, POST, etc.).
- Parameters: Including:
- Path parameters (e.g., /users/{id})
- Query parameters (e.g., ?sort=desc)
- Header parameters
- Body Parameters
- Query Parameters
- Request Body Schemas: For POST/PUT/PATCH endpoints, we extract the full request body schema including field types, nested objects, arrays, enums, etc.
- Security Schemes: We recognize apiKey, http, oauth2, and openIdConnect schemes to include authentication headers in requests.
- Servers: We detect server URLs and base paths to correctly form absolute request URLs.
- Content Types: application/json, multipart/form-data, etc., to send requests in the correct format.
This rich structure allows us to simulate valid requests exactly as a real client would — before injecting attack payloads.
🚀 Building Valid Requests with Realistic Data
Once we’ve parsed the spec, ApyGuard uses this data to generate valid request structures:
- Path parameters are filled with realistic placeholder values (/users/{id} → /users/123) (or overridden if needed)
- Query parameters are populated based on their defined types and constraints (or overridden if needed)
- Request bodies are constructed using object schemas, including nested fields
- Security headers or tokens are injected according to the declared security schemes (or overridden if needed)
- Servers are selected based on the servers list (or overridden if needed)
This ensures our scanner starts from a valid baseline — making detection of issues like unauthorized access, broken object-level authorization (BOLA), or insecure deserialization much more accurate.
🔧 Examples
✅ GET Request with Path & Query Parameters
OpenAPI snippet:
paths:
/users/{id}:
get:
parameters:
- name: id
in: path
required: true
schema:
type: integer
- name: verbose
in: query
required: false
schema:
type: boolean
ApyGuard request generated:
GET https://api.example.com/users/42?verbose=true
✅ POST Request with Request Body
OpenAPI snippet:
paths:
/articles:
post:
requestBody:
required: true
content:
application/json:
schema:
type: object
properties:
title:
type: string
content:
type: string
tags:
type: array
items:
type: string
ApyGuard request generated:
POST https://api.example.com/articles
Content-Type: application/json
{
"title": "Security Testing with ApyGuard",
"content": "Let’s explore how to secure your API endpoints...",
"tags": ["api", "security", "openapi"]
}
🛡️ Why This Matters for Security Testing
By understanding your OpenAPI spec, ApyGuard:
- Avoids false positives by making only valid, realistic requests
- Explores all authenticated and unauthenticated paths
- Adapts automatically when the API changes — no hardcoded test cases
- Enhances vulnerability detection for issues like:
- BOLA (Broken Object Level Authorization)
- Excessive Data Exposure
- Mass Assignment
- SSRF, IDOR, and more
Final Thoughts
OpenAPI isn’t just for docs — it’s the blueprint of your API. And ApyGuard uses it as a map for intelligent, automated, and accurate security testing.
Upload your OpenAPI document to ApyGuard and let us show you exactly what your API exposes—and how secure it really is.