Header

What Is Header?

Header shows the inspections applied to the header section of the request. The tab consists of two layers: at the top the common rule applied to all the headers, at the bottom the variable table in which the argument rules specific to certain headers are listed.

The HTTP Header Structure

The headers are the header fields that come after the request line and that are each a separate line in the Name: Value form. TR7 processes the header names by lowering them to lower case; the name matchings are therefore in effect independent of the case and in the records the names are seen in lower case. No parsing is applied to the values; the measurements are made over the raw content and in bytes. Every one of the inspections in this tab targets a certain element of the header section:

Example request headers:

Host: www.example.com
User-Agent: Mozilla/5.0
Accept-Encoding: gzip

Element	Its counterpart in the example	The related inspections
The header name (the key)	host, user-agent, accept-encoding	Header Key Length, Allowed / Required Headers
The header value	www.example.com, Mozilla/5.0, gzip	Header Value Length, Header Value Pattern, OWASP Check
The number of different header names	3	Header Key Count
The whole of the header block	The total of the three lines with their names, values, separators and line endings	Total Header Size
The repetition of the same header	In a request that sends two separate X-Tag lines, x-tag occurs 2 times	Header Value Count

Accessing the Screen

1. The rule is clicked in the Page Types list; the detail panel of the rule opens on the right.
2. The Header tab is clicked in the tab strip of the panel.

For the title elements of the panel and the behavior of the tab strip see Path. The value displays in the table also use the same form as in the Path tab: if there is no restriction No Restriction, the one-way restrictions ≤ n / ≥ n, the ranges [a - b], and the fields that are on/off are seen as ✓ / -.

The Detail Panel - The Header Tab

The inheritance and Rule Source

If the rule has not defined its own Header inspection, the values are inherited from the glob rule that matches the path or from the Any Paths rule according to the rule matching priority; the Rule Source row at the end of the table shows the path of the rule the inspections come from (for example Any Paths). If the rule defines its own Header inspection, the Rule Source row is not present.

The Header learning is not path based

Whichever of Analysis & Learning is used (Conditional Learning, AI Learning, Teacher) and in the teaching over Event Logs as well, the changes concerning the Header inspections are written to the Header inspection of the Any Paths rule; whichever path rule the request has matched, the result affects all the paths in the host group. The learning never creates a new rule or inspection specific to a path for Header; the headers are accepted as belonging not to a single path but to the whole of the site, and the related rule field in the attack record therefore shows All paths in the Header violations.

A Header inspection specific to a path can be defined only manually and is valid at runtime: in its own path it shadows the inspection of the Any Paths rule in the same scope. The learning methods never touch these inspections; the Header inspections specific to a path are managed only manually. The Path, Query and body (JSON, XML, Form, RAW) inspections, on the other hand, are learned per path.

The Add Common Rule for Header Screen

When the green plus icon Add common rule for Header button above the table is clicked, the form that defines the rule's own Header common inspection opens; with the save, the inheritance ends for that rule. If the rule already has its own Header inspection, the same button is seen as the pencil icon Edit common rule for Header (it opens the form with the current values) and Delete common rule for Header (it removes the common rule without asking a confirmation question). The add form does not open empty; it comes pre-filled with the related inspection values of the Any Paths rule. In the Any Paths rule itself, on the other hand, there is no delete button: the common inspection of the catch-all rule cannot be removed.

This screen is at the same time the edit screen: whether the common inspection has been added manually or has been formed by the learning, the form that opens with the Edit common rule for Header button shows the same fields below with the current values of the rule.

The Add Common Rule for Header Screen

INFO

Virtual Host Group

The host group to which the inspection will be added is shown as read-only; it is determined according to which group's Page Types screen the panel is opened from and cannot be changed from the form.

INFO

Path

The path of the rule to which the inspection will be added is shown; the form is bound to the rule for which the detail panel has been opened.

INFO

Area

It shows to which section of the request the inspection is applied. The field is locked to the tab the form is opened from: when the form is opened from the Header tab, it comes as Header and cannot be changed.

INFO

Argument Name

It shows the scope of the inspection. In the common rule form this field is locked as Any Arguments and the fields are applied to all the headers; a rule specific to a certain header, on the other hand, is defined from the Add Argument Rule for Header screen. The header name entered while an argument rule is being added is converted to lower case during the save.

If a header has its own argument rule, the value inspections of that header (Header Value Length, Header Value Pattern, Header Value Count, OWASP Check, Detailed Log) are taken entirely from this rule; the value inspections of the common rule are no longer applied to that header. The section-wide inspections (Header Key Length, Header Key Count, Total Header Size, Allowed / Required Headers), on the other hand, continue to be applied. Defining a rule specific to a name does not add that name to the Allowed Headers list by itself.

INFO

Header Key Length

The length restriction of the name (the key) of a single header is defined; the length is measured in bytes and every different header name is evaluated once:

Option	Meaning
No Restriction	No length restriction is applied.
Less Than or Equal To	The length must be equal to or below the entered value.
Equals To	The length must be equal to the entered value.
Greater Than or Equal To	The length must be equal to or above the entered value.
Range	The length must be between the two entered values (the limits included).

Only a number can be entered in the value field. Every header name that does not comply with the restriction is scored as a Header Key Length violation in the Structure Limits category and falls into the attack record.

INFO

Header Key Count

The restriction of the number of headers in the request is defined. The counting is done over the different header names; the repeated lines of the same name count as one:

Option	Meaning
No Restriction	No number restriction is applied.
Less Than or Equal To	The number of headers must be equal to or below the entered value.
Equals To	The number of headers must be equal to the entered value.
Greater Than or Equal To	The number of headers must be equal to or above the entered value.
Range	The number of headers must be between the two entered values (the limits included).

Only a number can be entered in the value field. A request that does not comply with the restriction is scored as a Header Key Count violation in the Structure Limits category and falls into the attack record.

INFO

Total Header Size

The total size restriction of the header section is defined. The size is measured in bytes over the whole of the header block excluding the request line; the header names, the values, the : separators and the line endings are included:

Option	Meaning
No Restriction	No size restriction is applied.
Less Than or Equal To	The total size must be equal to or below the entered value.
Equals To	The total size must be equal to the entered value.
Greater Than or Equal To	The total size must be equal to or above the entered value.
Range	The total size must be between the two entered values (the limits included).

Only a number can be entered in the value field. A request that does not comply with the restriction is scored as a Total Header Size violation in the Structure Limits category and falls into the attack record.

INFO

Allowed Headers

The list of the allowed header names is defined (a positive list). While the field is in the No Restriction position, all the header names are allowed; when the restriction is turned on, the names are added to the list one by one and every different header name that is not in the list is scored as an Allowed Headers violation in the Structure Policies category and falls into the attack record.

There is no implicit permission: the standard headers that the browsers send in every request (such as host, user-agent, accept) also produce a violation unless they are written into the list. Defining an argument rule specific to a header does not add that name to this list by itself.

The header names must be entered in lower case

The names in the Allowed Headers and Required Headers lists are compared exactly with the runtime state of the headers lowered to lower case and the list entries are not converted to lower case by themselves. An entry that contains an upper-case letter (for example X-Api-Key) does not match any header: in the Allowed list that header produces a violation in every request, and in the Required list the requirement can never be met. The names must always be entered in lower-case letters (x-api-key).

INFO

Required Headers

The list of the header names that are required to be present in the request is defined. While the field is in the No Restriction position, no requirement is applied; when the restriction is turned on, every one of the names in the list that is missing is scored separately as a Required Headers violation in the Structure Policies category. It is enough that the header be present in the request; its value may be empty.

INFO

Header Value Length

The length restriction of the header values is defined. The restriction is applied to every value of the header separately, over the raw content and in bytes; if the same header has arrived in more than one line, the value of every line is measured independently:

Option	Meaning
No Restriction	No length restriction is applied.
Less Than or Equal To	The value length must be equal to or below the entered value.
Equals To	The value length must be equal to the entered value.
Greater Than or Equal To	The value length must be equal to or above the entered value.
Range	The value length must be between the two entered values (the limits included).

Only a number can be entered in the value field. Every value that exceeds the restriction is scored as a Header Value Length violation in the Structure Limits category and falls into the attack record.

INFO

OWASP Check Default: Checked

When it is checked, the name and every value of every header are subjected to the OWASP signature scanning separately, in their raw state; for Header it is checked by default. The signature hits, differently from the structural violations, take part in the attack score by accumulating with their own scores. In the scanning, the signature set that is enabled on the OWASP Rules screen of the vService is used; for the listing of the signatures see Signature & Rule Library.

OWASP Exclusions

With this field that appears in the form when the box is checked, the OWASP rules to be excluded from the scanning are determined with a multiple selection; while the box is not checked, the field is not seen, and when no selection is made, Nothing chosen is written in the field. When an exclusion is defined, the number of the exclusions is shown next to the ✓ mark in the OWASP Check row in the detail panel.

INFO

Detailed Log Default: Checked

It manages the log detail of the signature (OWASP) hits; it is checked by default. While it is on, the matching content is shown together with its surrounding context in the Event Logs record; while it is off, the record still falls but instead of the content the phrase Detailed log disabled is seen. The summary information of the structural violations (for example the size comparison or the name of the violating header) is always written independently of this setting.

INFO

Header Value Pattern

The regular expression (regex) pattern the header values must match is defined. The inspection is positive: when the value does not match the pattern, a Header Value Pattern violation is produced in the Structure Policies category and the value itself is seen in the attack record. The pattern is searched anywhere in the value; if it is wanted that the whole of the value match, the pattern should be bounded with ^ and $. With the aA button next to the field the matching can be made case insensitive; this option is seen in the detail panel as the (-i) suffix next to the pattern. If no pattern is defined, no pattern inspection is applied to the value content.

INFO

Header Value Count

It is defined in how many separate lines (values) at most the same header name can take place in a request; only an integer can be entered in the field. When the limit is exceeded, a Header Value Count violation is produced in the Structure Limits category. If it is left empty, no repetition restriction is applied; if 0 is entered, even the presence of the header in the request counts as a violation.

INFO

Add

The common rule adding operation is completed by clicking the Add button; the button becomes enabled when no error remains in the form. There is no additional confirmation window or deployment (deploy) step; the WAF configuration is automatically produced again and applied and the values in the panel are updated instantly.

The mode behavior and the scoring

The structure inspections in this tab work only in the Blocking and Monitor modes; they are not run in the Learning mode, instead the restriction suggestions are learned from the observed traffic. The structural violations have a high score; at the default blocking threshold a single violation is enough for the request to be blocked in the Blocking mode (in the Monitor mode it is reported as an attack but the request is let through). The OWASP signature hits, on the other hand, reach the threshold by accumulating with their own scores.

Default Header Rules

The Any Paths rule comes together with 21 default header rules prepared for the frequently targeted headers; these rules are automatically added to the Any Paths rule as an argument rule each when the host group is created:

accept-encoding, connection, content-encoding, cookie, host, keep-alive, range, transfer-encoding, user-agent, x-forwarded-host, x-scanner, content-length, origin, upgrade, expect, authorization, sec-fetch-site, sec-fetch-mode, sec-fetch-dest, sec-fetch-user, referer

The rules limit the values the related header can carry with RFC based pattern and length restrictions and aim to close the header based attack vectors such as request smuggling and host header injection. Representative examples:

• host: the value must comply with a valid server address form; the header can be sent at most once.
• content-length: the value can consist only of digits and can be at most 16 bytes.
• cookie: it is limited to a single line and a minimum value length is required.
• authorization and referer: in these two rules OWASP Check is deliberately off: the content they carry (an encoded identity token, a URL) may produce a false alarm in the signature scanning. authorization carries only a length and single-line restriction; referer, on the other hand, is limited with a strict URL pattern.
• sec-fetch-site / mode / user: the values are limited with the known value sets these headers can take; sec-fetch-dest, on the other hand, is inspected with the allowed character set (since its value list widens over time).
• x-scanner: its repetition limit is 0: even the presence of this scanner-detection header in the request counts as a violation.

The Add Argument Rule for Header Screen

The Argument table below the common rule lists the argument rules specific to certain headers; with the search box of the table a filtering can be done over the name. The argument rules the rule defines itself are shown in bold, the inherited ones in italic. When the green plus icon Add argument rule for Header button above the table is clicked, the form that defines an inspection specific to a single header opens. In the Any Paths rule there is additionally the Suggested Argument Settings button next to this button.

When a row in the table is clicked, the detail of the argument rule opens below it; in the rule's own argument rule the pencil icon Edit (it opens the form with the current values) and trash can icon Delete (it removes the argument rule without asking a confirmation question) buttons are seen. In the inherited rows these buttons are not present; an inherited rule can be edited only from the rule that is its source.

In the rules specific to a path the add form does not open empty; the inspection fields come pre-filled with the common Header inspection values of the Any Paths rule. In the Any Paths rule itself, on the other hand, the form opens with the field defaults. This screen is at the same time the edit screen: the form that opens with the Edit button shows the same fields below with the current values of the rule; in the editing, differently from the add form, the Argument Name field is also locked; to which header the rule is bound cannot be changed afterwards.

The Add Argument Rule for Header Screen

INFO

Virtual Host Group

The host group to which the inspection will be added is shown as read-only; it is determined according to which group's Page Types screen the panel is opened from and cannot be changed from the form.

INFO

Path

The path of the rule to which the inspection will be added is shown; the form is bound to the rule for which the detail panel has been opened.

INFO

Area

It shows to which section of the request the inspection is applied. The field is locked to the tab the form is opened from: when the form is opened from the Header tab, it comes as Header and cannot be changed.

INFO

Argument Name

The name of the header to which the rule will be bound is defined. The scope selector is locked as One Argument in this form; the name is entered in the text box next to it and cannot be left empty (if it is left empty, the Enter argument name error is seen). The entered name is converted to lower case during the save and the headers are matched with their names lowered to lower case; therefore the matching is in effect independent of the case.

A second argument rule with the same name cannot be added; on an attempt the part collision error is returned. Since the name comparison is made before the conversion to lower case, the name must always be entered in lower-case letters; a name entered in upper case may create a duplicate rule for the same header next to the existing rule. In the edit form this field cannot be changed; if the rule is wanted to be moved to another header, it must be deleted and added again.

INFO

Header Value Length

The length restriction of the header values is defined. The restriction is applied to every value of the header separately, over the raw content and in bytes; if the same header has arrived in more than one line, the value of every line is measured independently:

Option	Meaning
No Restriction	No length restriction is applied.
Less Than or Equal To	The value length must be equal to or below the entered value.
Equals To	The value length must be equal to the entered value.
Greater Than or Equal To	The value length must be equal to or above the entered value.
Range	The value length must be between the two entered values (the limits included).

Only a number can be entered in the value field. Every value that exceeds the restriction is scored as a Header Value Length violation in the Structure Limits category and falls into the attack record.

INFO

OWASP Check Default: Checked

When it is checked, the name and every value of the header are subjected to the OWASP signature scanning separately, in their raw state; it is checked by default. When the box is removed, the header goes out of the signature scanning entirely together with its name and all its values; this is the way of exempting from the scanning a header that frequently produces false positives (among the default rules authorization and referer therefore come off). In the scanning, the signature set that is enabled on the OWASP Rules screen of the vService is used; for the listing of the signatures see Signature & Rule Library.

OWASP Exclusions

With this field that appears in the form when the box is checked, the OWASP rules to be excluded from the scanning are determined with a multiple selection; while the box is not checked, the field is not seen, and when no selection is made, Nothing chosen is written in the field. The exclusions are applied only to the scanning of this header; the other headers continue to use the exclusion list of the common rule.

INFO

Detailed Log Default: Checked

It manages the log detail of the signature (OWASP) hits; it is checked by default. While it is on, the matching content is shown together with its surrounding context in the Event Logs record; while it is off, the record still falls but instead of the content the phrase Detailed log disabled is seen. The summary information of the structural violations (for example the size comparison or the name of the violating header) is always written independently of this setting.

INFO

Header Value Pattern

The regular expression (regex) pattern the header values must match is defined. The inspection is positive: when the value does not match the pattern, a Header Value Pattern violation is produced in the Structure Policies category and the value itself is seen in the attack record. The pattern is searched anywhere in the value; if it is wanted that the whole of the value match, the pattern should be bounded with ^ and $. With the aA button next to the field the matching can be made case insensitive; this option is seen in the detail panel as the (-i) suffix next to the pattern. If no pattern is defined, no pattern inspection is applied to the value content.

INFO

Header Value Count

It is defined in how many separate lines (values) at most the header name can take place in a request; only an integer can be entered in the field. When the limit is exceeded, a Header Value Count violation is produced in the Structure Limits category. If it is left empty, no repetition restriction is applied; if 0 is entered, even the presence of the header in the request counts as a violation (among the default rules x-scanner is defined in this form).

INFO

Add

The argument rule adding operation is completed by clicking the Add button; the button becomes enabled when no error remains in the form. There is no additional confirmation window or deployment (deploy) step; the WAF configuration is automatically produced again and applied and the values in the table are updated instantly.

An empty field does not mean inheriting from the common rule

When the argument rule is saved, the value inspections of the header are taken entirely from this rule; the value inspections of the common rule are no longer applied to that header. The pre-filling in the form is only a starting convenience: after the save the fields are independent of the common rule and a field left empty (for example Header Value Count) does not return to the value in the common rule, it means no restriction for that inspection. The section-wide inspections (Header Key Length, Header Key Count, Total Header Size, Allowed / Required Headers), on the other hand, are not affected by the argument rule and continue to be applied.

The inheritance and the learning

The argument rules are also inherited according to the rule matching priority: if the rule has not defined its own argument rule for a header, the argument rule with the same name of the glob rule that matches the path or of the Any Paths rule becomes valid. The inherited rules are listed in italic in the table; in their detail the Rule Source row shows the path the rule comes from. When the rule defines its own argument rule for the same name, the inherited rule stays invalid for that rule.

The learning always targets the Any Paths rule in Header: if the header has an argument rule in the Any Paths rule (including the default rules), the updates are written to that rule; for example an exclusion is added to the OWASP Exclusions list, the length and repetition limits are widened. A Header Value Pattern that produces false positives, on the other hand, is not narrowed but cleared entirely. If the header has no argument rule, the change is written to the common rule; the learning does not create a new argument rule by itself.

---

Suggested Argument Settings

In the Header tab of the Any Paths rule there is the Suggested Argument Settings button with a blue import icon above the argument table; the button is seen only in this rule, it does not take place in the rules specific to a path and in the other tabs. When the button is clicked, the Are you sure? confirmation question is asked; when it is confirmed, the 21 default header rules are applied again to the Any Paths rule with their default definitions.

The operation covers only the 21 headers in the list: the rules that have been deleted are added again, the existing ones are returned to their default definition. The argument rules outside the headers in the list, the common rule and the rules specific to a path are not affected. With the save, the WAF configuration is automatically produced again and applied.

The customizations are replaced with the default definition

The operation does not preserve the customizations made for a header in the list (including the OWASP Exclusions exclusions added by the learning); the rule is replaced entirely with its default copy and the operation has no undo mechanism. The button should therefore be used when it is wanted to bring back the deleted default rules or to return the existing ones to their current default definition.