Main models in API security

Protecting an API cannot rely solely on traditional perimeter security; rather, it requires a layered approach that operates directly on top of the HTTP/S protocol, encompassing the application logic it protects. In this article, we list the key API security models provided by our cybersecurity suite, Perimetrical.

It operates at the edge, acting as a high-performance reverse proxy to the API origin. The WAF is a fundamental part of Perimetrical‘s cybersecurity strategy. It integrates into the platform and, with the flexibility of the Varnish Configuration Language (VCL), inspects the payload of each request:

Client → CDN (Edge) → [WAF Inspection + VCL logic] → Caché or API Backend

This configuration centralizes security and traffic management, allowing complex policies to be applied before a request consumes backend resources.

We can even complement this with our mid-tier servers to funnel requests prior to reaching the backend or client origin.

Negative and positive security models

Let’s first refresh the concepts of positive and negative security models.

The negative security model is the most common and is based on the principle of “blocking what I know is bad.” It’s easy to implement and maintain, as you only need to define rules for known attacks. It’s a reactive model, and its main weakness is that it can’t protect against unknown/new threats because it doesn’t have a signature for them.

The positive security model is exactly the opposite. It is based on the principle of “only allowing what I know is good.” It offers much stronger and more proactive protection because it only allows requests that respond to legitimate behavior. Here we are getting closer to the zero-trust objective, but its major disadvantage is how expensive and difficult it is to implement and maintain. A change in the API may require updating the rules so that it doesn’t block legitimate traffic.

The industry trend is toward hybrid security models that combine the best of both worlds and incorporate key aspects of each in response to today’s sophisticated attacks.

WAF: the negative security model

Integrated as part of the cybersecurity solution, the WAF provides the first line of defense based on a negative security model.

Using rule sets, such as the OWASP Core Rule Set (CRS), we inspect requests for known malicious patterns such as:

• Code injection (SQLi, XSS, etc.): detects and blocks attempts to inject malicious scripts or commands into request parameters.
• File Inclusion Attacks (LFI/RFI): prevents the exploitation of vulnerabilities that allow unauthorized files to be read on the server.
• HTTP protocol enforcement: ensures that requests adhere to RFC standards, discarding malformed traffic.

While essential protection, this model alone is insufficient, as it protects against known threats but not against zero-day attacks or abuse of business logic in requests made to our API.

OpenAPI schema validation: towards a positive security model

Herein lies one of the greatest strategic advantages of this architecture. Modern APIs are defined by a contract, usually an OpenAPI (or Swagger) specification file. This file isn’t just documentation; it’s a machine-readable definition of each endpoint, the allowed HTTP methods (GET, POST, PUT, DELETE), the expected parameters, and their data types.

Using the flexibility of the VCL, it is possible to load this specification once analyzed and apply a positive security model:

• Blocking unauthorized endpoints and methods: if a request is directed to an endpoint that doesn’t exist in the OpenAPI specification (e.g., /api/v1/internal/debug) or uses a method that isn’t allowed for a valid endpoint (e.g., a DELETE on /api/v1/users when only GET is allowed), the node network blocks it at the edge without needing to query the WAF or backend. This neutralizes exploration attempts and access to unexposed functionality.
• Strict parameter validation: request parameters can be verified to conform to the schema. For example, if an integer value is expected for a variable called userId and a string is returned instead, the request is invalid and rejected. This prevents a large category of injection attacks and backend processing errors.

This “what’s not explicitly allowed is prohibited” approach dramatically reduces the attack surface, overcoming the limitations of a signature-only WAF, while also avoiding unnecessary analysis costs.

Advantages of CDN caching for cacheable requests

Not all API requests should reach the backend. Idempotent read operations (primarily GET requests) are perfect candidates for caching.

• Reduced latency and backend load: serving a response from the CDN cache is much faster than processing it on the backend (which may require database queries, calculations, etc.). This dramatically improves Time-To-First-Byte (TTFB) and the customer experience.
• Increased throughput: by freeing the backend from repetitive requests, it can dedicate its resources to processing write operations (POST, PUT, DELETE) that are not cacheable. The result is a significant increase in overall system throughput.
• Granular invalidation control: our CDN allows for sophisticated invalidation policies. Objects can be purged from the cache instantly and accurately (e.g., purging /api/v1/products/123 when that product is updated) using cache tags or calls to our API, ensuring that stale data is not served.

DDoS protection at application layer 7

Modern DDoS attacks often aim not to saturate bandwidth (Layers 3 and 4), but rather to exhaust application resources (Layer 7) with seemingly legitimate but expensive-to-process requests. Perimetrical is exceptionally effective at mitigating these attacks.

Some of its main control points are:

• Rate limiting: using VCL, you can implement counters to limit the number of requests per IP address, authentication token, or any other identifier over a period of time. Requests that exceed the threshold are rejected with a 429 Too Many Requests code, without impacting the backend. Requests can also be denied or penalized via JS Challenge, Captcha, etc.
• Traffic spike absorption: the cache itself acts as a natural buffer. During an attack that repeatedly requests cacheable resources, our nodes absorb the impact, protecting the backend from overload.
• Client targeting and ACLs: VCL allows you to identify clients by their User-Agent, geolocation (GeoIP), TLS fingerprint, or behavior. This allows you to create dynamic access control lists (ACLs) to block malicious actors in real time.
• Anomaly management at your disposal: as detailed above, each site or vhost has its own configuration for anomaly reactions. This, of course, applies to API. In addition to the aforementioned control options, we can define automatic reactions for IP, traffic, bots, WAF vulnerability scans, etc., and apply them to our API.

Perimetrical is effective and proactive in protecting API

The combination of CDN, WAF, schema validation and anomaly management, combined with Layer 7 Anti-DDoS, creates a defense-in-depth architecture for API.

Perimetrical surpasses traditional security solutions by combining a negative model (WAF) with a positive model (schema validation), achieving robust and targeted protection. Additionally, its native high-performance caching and Layer 7 attack mitigation capabilities not only strengthen security but also dramatically optimize API performance, scalability, and resiliency.

Author: Óscar Dorrego

Psychologist by training, computer scientist by hobby, pre-sales by profession, new romantic at heart. He does so many things that he doesn’t even remember what he really does. More left hand than Nadal. Living between business and technology allows him to have half the joys and twice the worries, but it is impossible to make a dent in the spirit of our favorite snake charmer.