Apache Module mod_policy

Actions ¶

If a policy is violated, one of the following actions can be taken:

ignore

The policy check will be ignored for the given URL space, even if the filter is present.

log

The policy check will be executed, and if a violation is detected a warning will be logged to the server error_log, and a Warning header added to the response for the benefit of the client.

enforce

The policy check will be executed, and if a violation is detected an error will be logged to the server error_log, a Warning header added to the response, and a 502 Bad Gateway will be returned to the client. Optional links to explanatory documentation can be added to each error message, detailing the origin of each policy.

It is also possible to selectively disable all policies for a given URL space, should the need arise, using the PolicyFilter directive.

Alternatively, the PolicyEnvironment directive can be used to specify an environment variable, which if present, will cause the policies to be selectively downgraded or bypassed.

Policy Tests ¶

The following policy filters are available:

POLICY_TYPE : Enforce valid content types

Content types that are syntactically invalid or blank can be detected and the request rejected. Types can be restricted to a specific list containing optional wildcards ? and *.

POLICY_LENGTH : Enforce the presence of a Content-Length

The length of responses can be specified in one of three ways, by specifying an explicit length in advance, using chunked encoding to set the length, or by setting no length at all and terminating the request when complete. The absence of a specific content length can affect the cacheability of the response, and prevents the use of keepalive during HTTP/1.0 requests. This policy enforces the presence of an explicit content length on the response.

POLICY_KEEPALIVE : Enforce the option to keepalive

Less restrictive than the POLICY_LENGTH test, this policy enforces the possibility that the response can be kept alive. If the response doesn't have a protocol defined zero length, and the response isn't already an error, and the response has neither a Content-Length or is declared HTTP/1.1 and lacks Content-Encoding: chunked, then this response will be rejected.

POLICY_VARY : Enforce the absence of certain headers within Vary headers

If the Vary header contains any of the headers specified, this policy will reject the request. The typical case is the presence of the User-Agent within Vary, which is likely to cause a denial of service condition to a cache.

POLICY_VALIDATION: Enforce the presence of Etag and/or Last-Modified

The ability for a cache to determine whether a cached entity can be refreshed is dependent on whether a valid Etag and/or Last-Modified header is present to revalidate against. The absence of both headers, or the invalid syntax of a header will cause this policy to be rejected.

POLICY_CONDITIONAL: Enforce correct operation of conditional requests

When conditional headers are present in the request, a server should respond with a 304 Not Modified or 412 Precondition Failed response where appropriate. A server may ignore conditional headers, and this affects the efficiency of the HTTP caching mechanism. This policy rejects requests where a conditional header is present, and a 304 or 412 response code was expected, but a 2xx response was seen instead.

POLICY_NOCACHE : Enforce cacheable responses

When a response is encountered that declares itself explicitly uncacheable, the request is rejected. A response is considered uncacheable if it specifies any of the following:

• Cache-Control: no-cache
• Pragma: no-cache
• Cache-Control: no-store
• Cache-Control: private

POLICY_MAXAGE : Enforce a minimum maxage

When a response is encountered where the freshness lifetime is less than the given value, or the freshness lifetime is heuristic, the request is rejected. A response is checked in the following order:

• If s-maxage is present but too small; or
• If max-age is present but too small; or
• If Expires is present and invalid; or
• Date is present and invalid; or
• Expires minus Date is too small; or
• No s-maxage, maxage, or Expires/Date declared at all

POLICY_VERSION : Enforce a minimum HTTP version within a request

When a request is encountered with an HTTP version number less than the required minimum version, the request is rejected. The following version numbers are recognised:

• HTTP/1.1
• HTTP/1.0
• HTTP/0.9

Example Configuration ¶

A typical configuration protecting a server serving static content might be as follows:

<Location "/">
  SetOutputFilter POLICY_TYPE;POLICY_LENGTH;POLICY_KEEPALIVE;POLICY_VARY;POLICY_VALIDATION; \
    POLICY_CONDITIONAL;POLICY_NOCACHE;POLICY_MAXAGE;POLICY_VERSION

  # content type must be present and valid, but can be anything
  PolicyType enforce */*

  # reject if no explicitly declared content length
  PolicyLength enforce

  # covered by the policy length filter
  PolicyKeepalive ignore

  # reject if User-Agent appears within Vary headers
  PolicyVary enforce User-Agent

  # we want to enforce validation
  PolicyValidation enforce

  # non-functional conditional responses should be rejected
  PolicyConditional enforce

  # no-cache responses should be rejected
  PolicyNocache enforce

  # maxage must be at least a day
  PolicyMaxage enforce 86400

  # request version can be anything
  PolicyVersion ignore HTTP/1.1
</Location>

# suppress policy protection for server-status
<Location "/server-status">
  PolicyFilter off
</Location>