Schema Validation as a Security Control in Modern APIs

What Is API Schema Validation?

An API’s schema is its expected structure and data: there is no single schema, but rather a plethora of different schemas, dependent on the API’s own type. For instance, API REST commonly rely on JSON documents – rather than have every software vendor write their own RESTful API from scratch, the JSON schema provides a blueprint for how each API should handle their data structures.

API schema validation is the process of checking that the data sent to or received via API adheres to its individual schema. The operational difference is important – schemas are for easier API development; schema validation is the Seguridad de la API process that assesses whether an API is acting as expected.

Why Schema Validation Matters for API Security

Schema enforcement security means that each API is restricted to its explicit data types and parameters. Without it, attackers can exploit inconsistencies or overly permissive responses – a risk that’s exploded alongside the rapid implementation of APIs across all areas of an organization. 

Without schema enforcement, APIs represent some of the following risks:

Injection Attacks 

API injection attacks happen when the backend doesn’t sanitize an API’s input: an attacker can submit crafted input to the API, which the backend then handles as code, a query, or an object to be executed. Injection attacks can be thwarted by schema validation. For example, Twitter’s API shares data in the form of each tweet’s individual ID: since these are all numbers, this API can be expected to handle integers only. This allows an API gateway to recognize when strings are input into this integer-only API – and prevent the request from reaching the backend – ensuring API data integrity.

Excessive Data Exposure

APIs’ proximity to internal databases makes them at risk of excessive data exposure; this often happens when complete data objects are returned to the client, even when the request only needs a single item. This format essentially leaves it up to the client to pick and choose the data it needs. When that client is controlled by an attacker, however, this excess data can be repurposed into an attack. 

The precise mechanism through which it occurs can vary:

• Improper object handling: In some API frameworks, developers can return entire database objects directly as responses. For instance, a ‘user’ object includes the user’s username, password hash, and email. If a request is formatted without a specific attribute, there is a chance the unsecured API returns all of them.
• List endpoint abuse: List endpoints are specific URLs designed to return large collections of resources. If a client is able to request these large batch files, the risk of data leaks increases substantially. Authentication is key to preventing list endpoints from being misused.
• Older endpoints: These are often configured to return large amounts of data; since they’re also critical to an organization’s software capabilities, there’s significant risk of breaking things when the scope of this data is reduced. 

Whether it’s signposting what storage architecture your organization relies on, or granting unrestricted access to user PII, all unnecessary data represents a possible foothold for attack. A well-defined schema defines exactly which data fields an API is allowed to return, significantly reducing this risk.

Broken Authentication 

API authentication is just as important as user and endpoint authentication. However, time and financial restrictions can sometimes see developers cut back in this area. The resultant risks include:

• Incorrect server-side authentication: Servers that don’t verify validity metrics such as timestamps, sequence numbers, or single-use tokens are vulnerable to accepting replayed requests as legitimate. Attackers can then capture valid authentication requests and replay them to the server to gain unauthorized access.
• Weak authentication architecture: Commonly seen in legacy APIs, there are still some APIs that rely on fundamentally weak methods – such as static API keys. Since static keys don’t change unless manually rotated, a leaked or intercepted key can be used to access the API indefinitely.
• Broken object-level authorization: This attack relies on attackers changing an object ID in the request path, query, or body. If the API doesn’t verify that the caller owns the object in question, an attacker can view, edit, or delete others’ data. 

API schema validation can ensure that every connection adheres to API schema best practices, for instance, by declaring a single mechanism globally. Some common best-in-class options include OAuth2: this issues scope-based, time-limited access tokens that reflect the user’s individual role. With OAuth 2 validation in place, it’s possible to rapidly enforce API authentication best practices. 

How to Implement API Schema Enforcement

API schema enforcement generally relies on establishing an API gateway. From this central position, it’s then possible to authenticate and enforce API behavior. Organizations generally implement this across five stages:

1. Create or Obtain API Schema Files: schema enforcement begins by establishing which API is based on which schema. Each schema must accurately describe the API endpoints, alongside its paths, methods, request, and response payload structures. While it’s possible to do manually, API discovery tools can automate and expedite this process.
2. Upload or Integrate the Schema with an Enforcement Engine: The main tool behind schema enforcement is an enforcement engine. Upload the schema file to the enforcement engine’s configuration console or integrate the schema within your API management system.
3. Select Enforcement Mode: Begin with a “Detect” or “Monitor” mode to log requests that deviate from the schema without blocking them. This phase helps validate your schema accuracy and catch legitimate API usage patterns before enforcing restrictions.
4. Configure Enforcement Scope: Decide if enforcement applies to the entire schema or only specific API endpoints or operations. This is a better choice if a gradual rollout is on the roadmap, or if you want focused protection on sensitive endpoints.
5. Enable Prevention Mode:  After successful detection and tuning, switch the enforcement engine to “Prevent” mode, and actively block non-compliant API traffic, unauthorized data, and malformed requests.

With a functioning schema validation system in place, it becomes possible to actively monitor the real-time activity and security posture of your organization’s APIs. However, doing all of this in-house can place more stress on your pre-existing security team, which is where a full-automation solution like Check Point can help.

Automatically Discover and Secure All APIs with Check Point WAF

Check Point’s CloudGuard WAF automatically discovers APIs: by routing all API and application traffic through its firewall, it’s able to analyze traffic in real time. This discovery process identifies all active APIs, including shadow endpoints that may be undocumented or forgotten.

It then automatically establishes which schema each API is based on by inspecting request URIs, headers, and API payload validation. Any API with a tenuous or unclear schema is added to a manual check queue, where it can be verified, placed under a schema, and enforced from there.

From there, all incoming requests are analyzed from a dual-layer AI engine – the first process checks for indicators of known attacks, such as broken authentication – while the second monitors activity to detect deviations from normal behavior. The result is a rule-free, context-aware security platform that enforces API schema from the CI/CD pipeline. Explore how CloudGuard defends APIs with a demo.