Content Type Handler

Purpose

The Content Type Handler limits the permitted content types for requests.

Requests that state an invalid content type are denied by vWAF with an HTTP error code conforming to the HTTP protocol: 405 (method not allowed), 415 (unsupported media type) or 413 (request entity too large).

For more information regarding adding and editing Handlers, see Editing Handlers.

Severity

Events triggered by this handler are given the severity: low. (For details on severity levels, see Severity of Events Triggered by Handlers).

Recommendations for use

Use the Content Type Handler to allow only those content types that your web application actually processes.

Attributes

Attribute	Meaning
replace missing content type	Optional: Here you can specify a content type that vWAF inserts into all requests that don't specify any content type. ATTENTION If you enter a replacement content type here, make sure that you've allowed the corresponding content type. Alternatively, you can enter the replacement content types application/x-www-form-urlencoded or multipart/form-data and enable the corresponding option allow urlencoded or allow multipart.
allow post without content type	When this option is enabled, vWAF accepts all POST requests that don't state a content type. Default: disabled Only enable this option if you can't avoid doing so. Enabling this option can for example be necessary if you have some locally running Perl scripts or other programs that generate POST requests without specifying a content type. Browsers don't create requests without content type.
allow urlencoded	When this option is enabled, vWAF accepts requests that have the content type application/x-www-form-urlencoded. Default: enabled
allow multipart	When this option is enabled, vWAF accepts requests that have the content type multipart/form-data. Default: enabled
allow json	`{ "foo" : "bar", "foo2" : { "bar2" : true, "bar3" : 42, "bar4" : ["hello", "world"]} }` `foo=bar foo2.bar2=true foo2.bar3=42 foo2.bar4_0=hello foo2.bar4_1=world` When this option is enabled, vWAF accepts requests that have the content type application/json. Default: disabled Internally, vWAF converts incoming JSON data into a flat key-value structure so that it can be handled similar to other data by further handlers. For example, the JSON object is interpreted as the following key-value pairs:
allow xml	`<?xml version="1.0"?> <items> <item1> value1 </item1> <item2> value2 </item2> <item1> value3 </item1> </items>'''` `key: "items.item1" value: "value1" key: "items.item2" value: "value2" key: "items.item1" value: "value3"` Enable this option if you require vWAF handlers to process XML content as key/value pairs and vWAF to apply baseline checks on XML requests. If enabled, vWAF parses XML content. Default: disabled vWAF converts the incoming XML into a flat key-value structure so that the data can be processed by other handlers. Here is an example of how an XML document is converted: Incoming XML request body: Converted to the following key-value pairs:
content type parser mapping	Here you can enter a list of content types that you want vWAF to accept in addition to those allowed by allow urlencoded, allow multipart, and allow json. For example, although the standard content type for JSON bodies is application/json, some applications use other content types here, such as text/json, application/javascript, and others. Use Regular Expressions to specify the content types. In addition to the content type, you need to specify which parser vWAF should use for parsing the request body. vWAF has three different parsers plus two additional options. This gives you the flexibility to handle all possible scenarios: pass through (do not parse) Tells vWAF not to parse the request body at all. Therefore, all subsequent handlers that inspect the request body will see an empty parameter list. parse as x-www-form-urlencoded Tells vWAF to parse the request body as URL-encoded data. parse as multipart/form-data Tells vWAF to parse the request body as multipart-encoded data. parse as JSON Tells vWAF to parse the request body as JSON-encoded data. invalid content type Tells vWAF not to handle the request but to deny it. Usually, this is equivalent to not adding the content type to the list at all. However, the option can be useful when a subsequent content type in the list includes a catch-all rule.
check upload content types	When this option is enabled, vWAF also checks the content type for multipart/form-data file uploads and only accepts uploads if the used content type is on the list in allow upload content type list. You can use this, for example, to allow only the upload of pictures or other specific data.
allow upload content type list	Here you can enter a list of content types that vWAF accepts for uploads if the option check upload content types has been enabled.
usertext	Optional: Here you can specify some text that vWAF adds to the log file entries created by this handler. You can use this, for example, to document why you've added the handler to your configuration, and how the handler is intended to behave.
enable logging	Disable this option if you do not want vWAF to create a log file entry when the handler is executed. This can be useful to keep log files smaller in case the handler creates a large number of entries but you don't need these entries. When in detection mode, disabling logging de facto makes the handler ineffective. Disabling logging also prevents the actions of the handler from being taken into account for the Top-10 lists in Attack Analysis, and from being listed in Reports.To decrease the size of the log files, also consider to enable reduced logging, which excludes all non-handler-related information from the log files (see Editing Applications).

For details regarding entries added to the log file by this handler, see the relevant section in Entries in Application-Specific Log Files.