API Protection
Last updated
Was this helpful?
Last updated
Was this helpful?
CloudGuard WAF has strong capabilities to protect Web Servers from malicious attacks, whether those servers serve human customers via a Web Application or programmatic access via Web APIs.
When serving Web APIs for programmatic access the server exposes API for external use. Over time that API changes. New APIs are added, new versions of existing APIs are created, parameters within an existing API might be added as well and APIs can be deleted.
Best security is achieved when we:
Allow traffic to reach the web server only if it matches an approved API with correct parameters.
Are able to maintain the API schema - Review changes and allow only traffic for reviewed changes to pass, as well as prevent access to deleted/deprecated APIs.
Approve which API usage can contain sensitive data, to prevent data leaks.
Given the life cycle of a web server, providing APIs to its users - as APIs are added, sometimes modified or deleted, sometimes very frequently - a security administrator needs a solution that will rise to challenge of not only approving a schema and enforcing it, but also comparing that schema to the actual usage to make sure there are no security holes, yet prevent connectivity issues.
The combination of the main two offerings of CloudGuard WAF provide the best API security:
API discovery - Providing Security by Visibility. Providing a schema, as learned by the API discovery engine, and analysis of API usage. Periodic analysis of the findings allows the security administrator to keep up with the fast development process of the web server's APIs, while not compromising its security.
API Schema Validation - Preventing traffic that does not conform with the approved schema for the Web API asset's APIs. The initial schema can be:
API Discovery engine's schema (Recommended). This allows the schema to continue to be maintained and reviewed as additions will create new suggested schema versions to be approved by the security administrator. It is always possible to use API Discovery's schema as the basis and add on top of it, manual changes.
An approved and maintained schema file created by your own development processes. API discovery can still be used to review suggested changes according to the traffic sent to the web server and passing through CloudGuard WAF's agent.
The Endpoint in REST APIs is the URI without the domain. i.e. "/api/my-assets" in "https://myapp.com/api/my-assets".
However, REST-based endpoint can contain "path parameters" which essentially combine different endpoints to a single one with the same meaning. For example, joining /api/my-assets/asset-id-4af4, and /api/my-assets/asset-id-8d2a into a single /api/my-assets/{asset-id} that represents all the potential APIs that have this format, have different asset IDs, yet serve the same purpose in terms of security configuration, and request body structure.
In GraphQL the endpoint is the function being called.
In REST APIs the method is the HTTP protocol method. i.e. GET, POST, PUT, etc.
When using GraphQL there are 2 main methods - query (indicating a read-only endpoint) and mutation.
An API is the combination of a method and an endpoint. i.e. POST /api/my-assets/{asset-id}.
An API can have additional query parameters with certain value formats, unique headers with certain value formats, and body with a specific structure - usually a JSON format.
The API's additional/optional query parameters, and the request body's structure, is learned as well the more usage of the same API is seen, and its accepted structure is also built as part of the schema.
Sensitive Data types whose usage is detected by API discovery include:
UUIDs.
Emails.
Credit Card Numbers.
IP and MAC addresses.
Social Security Numbers.
Phone Numbers.
IBAN.
SSH Keys.
Certificates.
Vehicle Identification Numbers.