API
The Gcore Customer Portal is being updated. Screenshots may not show the current version.
WAAP
WAAP
API
Chosen image
Home/WAAP

Protocol validation

The protocol validation policy group verifies the HTTP and HTTPS protocols used by clients to request content from your website's origin server. If the request meets the protocol-specific requirements, the transaction is allowed. All non-compliant transactions are blocked.

Protocols overview

Clients use HTTP methods to communicate with the website's origin server and specify what action should be performed on the requested resource. The following are nine standard HTTP methods that the Gcore WAAP looks for when validating traffic.

Name Description
GET Retrieve a URI.
HEAD Retrieve a URI without the response body.
POST Submit data to a resource and create a new entity.
PUT Update all data in a resource entity.
DELETE Remove a resource.
CONNECT Establish a connection with a resource.
OPTIONS Request information on the communication options associated with a resource.
TRACE Echo a request back to the client (mainly for debugging purposes).
PATCH Update data in a resource entity.

Configure policy group

You can review the Protocol validation policy group and enable or disable its policies in the Gcore Customer Portal:

1. Navigate to WAAP > Domains.

Domains page in the Customer Portal

2. Find the domain where you want to configure the policy group and click the domain name to open it.

3. In the sidebar menu, click WAAP.

4. On the Policies page that opens, click Protocol validation to expand the section and adjust the policies.

WAAP policies page with the highlighted ehavioral WAAP policy

All Protocol validation policies are enabled by default. To enable or disable a policy, turn on the toggle near that policy.

Invalid user agent and unknown user agent

These two WAAP policies work together to identify and block requests that miss a standard user-agent parameter. If the agent is missing, this can indicate that an illegitimate client is being used.

Most browsers provide user agent information across the network to validate a client's authenticity and purpose. user-agent strings typically follow this syntax:

User-Agent: <product> / <product-version> <comment>

Where:

  • <product>: A product identifier—its name or development codename.

  • <product-version>: Version number of the product.

  • <comment>: Comments containing more details. For example, sub-product information.

This is the common format of a user agent generated by a web browser:

User-Agent: Mozilla/5.0 (<system-information>) <platform> (<platform-details>) <extensions>

The following is an example of a user agent generated by a Windows XP user browsing a website via Google Chrome:

Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/98.0.4758.102 Safari/537.36

This user agent indicates that the user is using Windows 10 (Windows NT 10.0), a 64-bit system (Win64; x64), and the latest version of Chrome (98.0.4758.102) at the time of browsing.

Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/98.0.4758.102 Safari/537.36

This user agent indicates that the user is using macOS (Macintosh), specifically version 10.15.7 (Intel Mac OS X 10_15_7), and the latest version of Chrome (98.0.4758.102) at the time of browsing.

Service protocol validation

Block clients that try to interfere with the service's internal calls, such as tampering with cookies or request headers.

Prevent malformed request methods

Enforce HTTP RFC requirements that define how the client is supposed to interact with the server. If the requests don’t meet the RFC standards, a client will be challenged with CAPTCHA or JavaScript validation. Clients that fail to pass the validation will be blocked.

Was this article helpful?