To save configuration changes or edits you make to any features and options, you must click Save on the lower-right of the section or page where you are making changes. Click apply changes on the upper-left corner of the page, and then click OK. Your changes will not be stored if you do not properly save your changes.

The Web applications section allows for defining scope for specific web application and API endpoint URL paths with different policy rules for select policy components.

Web applications and API endpoints are either added manually or they are automatically created by tuning automation, API management automation (based on the API definition), or by the learning engine.

Web application and API endpoint policy rules define a set of (predominantly positive) validation criteria for requests targeting the specific web applications or API endpoints the policy rule covers.

Proxy mode

Requests with data in the request body (also known as “POST requests”) can either be buffered or streamed to the protected backend.

• Buffer mode: Buffers and inspects the entire HTTP request body up to the configured limit before passing it to the backend server. This is the default and recommended mode as it provides the most comprehensive inspection and protection capabilities, including against slow DoS attacks. HTTP requests with content length exceeding the configured limit will be denied.

• Streaming mode: Allows for an UNLIMITED HTTP request body size as it streams and inspects data in chunks. When the request body is parsed, individual parameter names and values are still subject to their own limits. When using this mode, some controls are not supported or behave differently:
  • Request body size is unrestricted
  • Allowed HTTP methods, protocol versions, and web services are configured in the web application scope
  • The POST section of Policy > Protocol Restrictions > Request parameters, restrict size and number is replaced by web application scope limits (when content type is parsed, otherwise they are not enforced)
  • CSRF protection is not enforced on streaming requests
  • When the content type is not parsed, the request body inspection is limited to the raw data stream, and controls that are parameter-specific, such as named parameter rules, cannot be enforced
  • Virtual patching is ineffective as rules are not applied to request body content

  The Streaming mode is recommended when the request body size is expected to be large or unlimited, resulting from factors such as file uploads or large JSON/XML payloads.

Scope

Web application and API endpoint rules are defined by a pattern that matches the incoming request URL path to select the specific web application policy definition. The pattern defines the scope of the policy rule.

A regular expression or OpenAPI syntax defines the scope pattern. A full match is implied (^regular expression$); the caret (^) and dollar ($) characters do not have to be included in the regular expression.

Scope overlap

Web application and API endpoint rules are listed in the validation order. Since the patterns that define the application rule scopes are regex-based, it is possible that they overlap as in the case of “.+\.aspx” vs “/morespecific/.+\.aspx”.

If scopes are overlapping, change the validation order so that more specific rules are evaluated first. In the case above, “/morespecific/.+\.aspx” should be evaluated before “.+\.aspx”.

The validation order can be changed in the "Web application validation order" section, located above the "web applications" group in the policy.

URL-based parameters

For API endpoints, Fortra WAF supports the OpenAPI parameter definition syntax where named input parameters extracted from the URL path are in curly quotes, such as /users/{id}.

When creating a web application of type OpenAPI Path, a definition such as /users/{id} is translated to a regular expression that matches the path ^\/users\/([^\/]+)$ (“/users/” followed by “non-/” until end-of-string).

When an incoming request URL path matches the resulting API endpoint scope regex, data is extracted from the part of the URL path following “/users/” assigned to the parameter “id”. The data is then validated using the policy rules within the web application scope that apply to the specific parameter “id”.

Non-API web applications that read parameters from the URL path can be created using the API path syntax as required.

Payload size override

When uploads are allowed in Policy > Protocol restrictions > File uploads allowed, the upload max size overrides the POST form payload limit set in Policy > Protocol restrictions > Request, restrict length and number.

In turn, the payload size override allows for overriding the max upload size defined in Policy > Protocol restrictions > File uploads allowed.

File uploads must be allowed for the setting to be active.

Session protection

Require a valid session to access this resource Check box	Enable / disable authorization of access to this resource based on session validity. If enabled, whenever this resource is requested, WAF will only allow the request if it originates from a valid user session. Note that session protection and request authorization have to be enabled for resource request authorization to be effective. See Session and CSRF protection Default: <disabled>
Enable request origin validation for this application Check box	Enable / disable validation of requests resulting from forms with this application as action. If enabled, whenever a request for this application contains a specific parameter (see below) it is verified that the request origins from a form on a web page/application belonging to the web system and that the form has been issued on a page belonging to the current users session. Note that for the validation token to be generated Generate request form validation tokens (CSRF protection) has to be enabled. See Session and CSRF protection. Default: <disabled>
Validate parameter name Input field	String specifying the name of a specific parameter to be present for WAF to perform request origin validation. Valid input A string defining a parameter name. Input example amount Default value <none>

Streaming name/value limits

When Proxy mode is set to Streaming, limitations on the parameter name (key) and value defined in Policy > Protocol restrictions > Request, restrict length and number do not apply within the scope of the application/endpoint rule since much larger values are possible due to the payload being parsed and validated while streamed to the protected web server.

Streaming name/value limits only apply to content types that are parsed (that is, the payload that is being processed by the WAF engine, extracting name=value pairs from it):

• Name – bytes: maximum allowed name size. Maximum value allowed is 1024 bytes.
• Value – bytes: maximum allowed value size. Maximum value allowed is 16777216 bytes (16 MiB).

If an unlimited name or value size is required, the content type in question can be set to unparsed and raw inspection. Not parsing a content type has the drawback that name-based policy rules do not apply and payload inspection becomes similar to an IDS/IPS.

Streaming HTTP body inspection signature exceptions

The dominant tuning methodology in Fortra WAF is to make exceptions for a specific named input, preferably within the particular scope of a web application/API endpoint rule. A key requirement for this methodology is that HTTP requests are parsed and the input is assigned to name=value pairs.

If a content type is not parsed (either because the content type is not supported or because of size requirements), the named input exception method is not possible, and the only options are to bypass the application (as defined by URL path) entirely, disable entire signature classes globally, or to exclude specific named signatures in the scope of the URL path.

This option allows for the latter, disabling named signatures specifically within the scope of the URL path.

To disable a signature: Copy the signature name from the deny log record and then insert it into the input area. Multiple signatures must be separated by a new line.

Streaming content types

Defines how different Content-Types in HTTP requests are handled when HTTP body streaming is enabled.

Content types can be set to either be parsed or not parsed. When a content type is parsed, individual parameter names and values are still subject to their own limits, per Streaming name/value limits.

When a content type is not parsed, request body inspection is limited to the raw data stream and controls that are parameter specific (for example, named parameter rules cannot be enforced).

The default rule (Content-Type: DEFAULT) should always be present and defines how all other content types not explicitly listed are handled.

Parse

Content types can either be parsed by assigning values to named inputs or processed as raw payloads.

When a content type is parsed, more granular policy rules and tuning exceptions are possible as rules can be specified for the named input.

The option to not parse a content type should only be chosen if the content type is not supported or requirements for very large input mandate it.

Validation method

The (advanced) WAF signatures are each flagged for what request elements they are suitable for. The Validation method determines how signatures are selected, and which signatures are used for validating a content type.

• Advanced: The advanced signature model is used. Signatures are selected based on input type and connection trust.
• Raw: Only signatures suitable for raw unparsed input will be used.
• Upload: Only signatures intended for file uploads are used.
• Bypass: Content type is bypassed and not validated.

Adding a content type

1. Click Add new.
2. Enter the content type in the Content-Type box.
3. Select yes or no to allow or disallow the content type.
4. In the Parse box, select yes or no to enable or disable parsing of the content type.
5. In the Validation box, select the desired validation method.

DEFAULT content type

The DEFAULT rule defines how all content types not explicitly listed are handled.

If set to parse, supported content types will be parsed and individual parameter names and values are still subject to their own limits. Unsupported content types will be treated as "not parse" and validated using "raw" signatures.

It is recommended to set the DEFAULT rule to "not parse" when parameter names or values are expected to be larger than allowed.

When content type is not parsed, request body inspection is limited to the raw data stream and controls that are parameter specific (for example, named parameter rules cannot be enforced).

Attributes

Informational, read only.

Shows the type of policy rule: Web Application or API Path Definition. If built from an API definition, it shows the name of the API definition.