Main API Security Models

APIs are the lifeblood of modern applications. They're also the most targeted attack surface. SQL injection, XXE, broken authentication, lateral movement — all enter through APIs.

At Perimetrical, we believe API security requires a layered approach. Not just blocking what's bad (negative security), but also allowing only what's good (positive security). Let's explore both models and how they work together.

The Architecture: Reverse Proxy with Edge Protection

Our model places a CDN-based reverse proxy between clients and your backend API:

Client → CDN (Edge) → [WAF Inspection + VCL Logic] → Cache or Backend API

This simple architecture unlocks tremendous power:

• Edge inspection: security decisions happen at the CDN edge, not at your origin
• Low latency: legitimate requests pass through in microseconds
• Scalability: DDoS and bot attacks are absorbed at the edge, never reaching your origin
• Caching: cacheable API responses reduce origin load and improve performance

Model 1: Negative Security Model (Deny the Bad)

The traditional security model: assume everything is legitimate unless proven otherwise. Block known attack patterns.

WAF: Core of Negative Security

A Web Application Firewall (WAF) inspects incoming traffic and blocks requests matching known malicious patterns:

• OWASP Core Rule Set (CRS): maintained by a security community, these are battle-tested rules for common attacks
• SQL Injection (SQLi) detection: identifies commands like UNION SELECT, DROP TABLE, or encoded payloads
• Cross-Site Scripting (XSS) detection: blocks JavaScript injection, event handlers, and iframe attempts
• Local File Inclusion (LFI) / Remote File Inclusion (RFI): prevents traversal attacks (../../../etc/passwd) and remote script loading
• HTTP protocol enforcement: rejects malformed headers, oversized content, and invalid methods
• Session fixation & CSRF prevention: validates token patterns and origin headers

The WAF operates with signature-based and behavioral detection. It's effective against known attacks but can generate false positives and requires continuous rule updates.

Limitations of Negative Security Alone

• Known vulnerabilities only: zero-day attacks and novel techniques slip through
• Evasion attempts: attackers use encoding, polymorphism, and obfuscation to bypass rules
• False positives: legitimate requests sometimes match attack signatures (especially in user-generated content)
• Rule maintenance: requires constant updates as new attack patterns emerge

Model 2: Positive Security Model (Allow the Good)

A more modern approach: instead of blocking what's bad, only allow what you've explicitly defined as good. This requires API schema definition.

OpenAPI Schema Validation

OpenAPI (formerly Swagger) allows you to define your API contract: endpoints, methods, parameters, data types, and constraints.

Using this schema, Perimetrical enforces:

• Endpoint whitelisting: only defined endpoints are accessible; undefined routes return 404
• HTTP method enforcement: an endpoint defined for GET is not accessible via POST, PATCH, or DELETE
• Parameter validation: required parameters must be present, optional parameters are ignored if not needed
• Data type enforcement: integer parameters must be integers, strings must match defined length, dates must be valid
• Enum validation: if a parameter accepts only "active" or "inactive", anything else is rejected
• Schema compliance: JSON payloads must conform to the defined schema; extra fields are rejected or normalized
• Range validation: numeric fields stay within min/max bounds, strings within length limits

Example: A `/api/users/{id}` endpoint defined as GET-only with `id` as a positive integer will:

• Accept: `/api/users/123` ✓
• Accept: `/api/users/999999` ✓
• Reject: `/api/users/abc` ✗ (not a valid integer)
• Reject: `/api/users/123/delete` ✗ (path traversal attempt)
• Reject: `POST /api/users/123` ✗ (wrong HTTP method)

Advantages of Positive Security

• No false positives: only requests matching your API contract are allowed
• Zero-day protection: unknown attack techniques are automatically blocked if they violate the schema
• Documentation-driven: your OpenAPI spec is both documentation and security policy
• Minimal maintenance: rules change when your API contract changes, not when new attacks emerge
• High confidence: you know exactly what traffic is valid; everything else is malicious

Limitations of Positive Security Alone

• Requires API schema: not all applications have formal OpenAPI definitions
• Business logic blind: validates the format but not the intent (e.g., allows SQL inside a properly-formatted string parameter)
• Performance overhead: schema validation on every request has latency cost (though minimal on modern CDNs)

CDN Caching Advantages for Cacheable Requests

Not every API request is dynamic. Read-heavy APIs for configuration, catalogs, or reference data are excellent caching candidates.

• Latency reduction: cached responses served from edge in microseconds vs. origin in milliseconds
• Throughput multiplication: a single origin request serves 100,000 cache hits
• Origin protection: cache layer absorbs read traffic spikes, protecting origin from overload
• Granular invalidation: CDN-based purging (URL, tag, or time-based) keeps content fresh without cache stampedes
• Cost reduction: fewer origin requests = lower egress costs and reduced database query load

Layer 7 Application DDoS Protection

Beyond WAF and schema validation, Perimetrical adds behavioral DDoS protection at the application layer:

• Rate limiting: per-IP, per-user, or per-API-key request limits with automatic blocking
• Traffic absorption: DDoS traffic is absorbed at the edge; legitimate origin traffic continues
• Client targeting: apply stricter limits to untrusted clients (new IPs, known botnets)
• ACLs (Access Control Lists): whitelist trusted partners, block known malicious ASNs
• Anomaly management: automated response to behavioral anomalies (sudden traffic spike, geographic shift)

The Hybrid Approach: Combining Both Models

The best API security combines negative and positive security:

1. Layer 1 (Edge): WAF blocks obvious attacks (known SQLi, XSS, etc.) — fast, signature-based, catches the 90% of automated attacks
2. Layer 2 (Edge): OpenAPI schema validation enforces your API contract — no false positives, zero-day resistant
3. Layer 3 (Edge): DDoS & behavioral protection blocks abnormal traffic patterns
4. Layer 4 (Edge): Caching serves legitimate requests from edge; origin only handles cache misses
5. Layer 5 (Origin): Application-level validation as a final defense — validates business logic constraints

This layering ensures:

• 99% of attacks are stopped at the edge, never reaching your origin
• Legitimate traffic experiences minimal latency
• Your origin runs lean, serving only legitimate cache misses
• Recovery from attacks is fast because edge nodes are stateless and distributed

Implementation at Perimetrical

Our platform makes this simple:

• Upload your OpenAPI spec to the dashboard
• Enable WAF protection with one click
• Configure caching rules for cacheable endpoints
• Set rate limits per endpoint or global
• Monitor in real-time: live traffic, blocked requests, origin response times

Conclusion

API security in 2025 demands more than signature-based WAF rules. Modern APIs need a hybrid approach: negative security to catch known attacks, positive security to enforce your API contract, and behavioral protections to mitigate DDoS. Combined with edge caching and CDN intelligence, this creates an impenetrable shield around your API infrastructure.

The result is faster APIs, fewer security incidents, and lower origin load — all without sacrificing the user experience.