HTTP / HTTPS / WS / WSS URLs

Here’s an in-depth view on HTTP / HTTPS / WS / WSS URL handling in Application Security Policies, particularly focusing on Allowed URLs, Header-based Content Profiles, CORS (Cross-Origin Resource Sharing) settings, and enforcement options.

Adding Allowed URLs

When setting up security rules for URLs, there are different ways to define URLs that can be allowed within your security policy:

Explicit URLs vs. Wildcard

• Explicit URLs: These specify a unique, precise URL that should be allowed.

  • Example: https://www.example.com/api/users/*

• Wildcard URLs: This uses a wildcard pattern to specify a broad set of URLs.

  • Example: https://www.example.com/api/*

Learning Options

Security systems offer various learning options for adding explicit URLs:

• Never (Wildcard Only): No explicit entities are added, allowing only wildcard expressions.

• Selective: System adds explicit entities only if false positives are detected.

• Compact: Only suggests entities with a high learning score.

• Always: System creates a "Comprehensive Whitelist" of URLs.

Header-based Content Profiles

When defining security rules for allowed URLs, Header-based Content Profiles play a crucial role:

• Request Header Name: Specifies the name of the request header that must appear in the request for the allowed URL.

  • Note: This field is case-sensitive.

• Request Header Value: Defines a pattern string (e.g., *json*) that must appear in legal requests.

• Request Body Handling: Indicates how the system parses the content of requests for allowed URLs.

  • Form Data: Parses content as posted form data in URL-encoded formats.

  • This setting will enforce form parameters according to the security policy.

• Profile Name: Specifies the XML, JSON, GWT, GraphQL profiles the security policy uses when examining requests based on the Content-Type header field.

HTML5 Cross-Domain Request Enforcement (CORS)

CORS Use Cases

• Simple Requests: Applies when using HTTP methods GET, HEAD, and POST.

  • Note: Only Content-Type values like text/plain, application/x-www-form-urlencoded, and multipart/form-data are supported.

• Preflight Requests: This is when Simple Requests cannot be applied, and an initial OPTIONS request checks what can be done in the context of cross-origin requests.

CORS-Related Headers

In response to Preflight Requests, the system uses CORS Response Headers:

• Access-Control-Allow-Origin

• Access-Control-Allow-Methods

• Access-Control-Allow-Headers

• Access-Control-Max-Age

Handling CORS Requests in the Enforcement Mode

When configuring the enforcement mode for CORS requests, you have several options:

• Disabled: No action is taken; requests are passed directly to the server.

• Remove All CORS Headers: Remove all CORS headers from the response. Browsers will not allow cross-origin requests.

• Replace CORS Headers: Replace CORS headers in the response with those specified in your security policy (e.g., Allowed Origins, Allowed Methods).

• Enforce on ASM: Allow CORS requests as configured in the Allowed Origins setting. CORS requests are only allowed from domains listed in the Allowed Origins tab.

Sample Snapshot of CORS Settings

Here’s a sample snapshot that illustrates checking the Allowed Origin List via the last CORS settings configuration:

• Allowed Origins list that contains approved domains.

• Allowed Methods (e.g., GET, POST, OPTIONS)

• Allowed Headers (e.g., Content-Type, Authorization)

• CORS Response Headers configured to allow specific origins.

---

By setting up allowed HTTP/HTTPS/WS/WSS URLs, managing Header-based Content Profiles, and configuring CORS settings properly, you can effectively enforce security policies that balance security and application performance while ensuring that legitimate traffic is not blocked unnecessarily.

This configuration will help:

• Prevent Cross-Origin Resource Sharing (CORS) attacks.

• Monitor and validate allowed traffic and requests.

• Enforce security policies across your application’s network traffic.