Skip to main content

HTTP Security Headers

In accordance with Boise State information technology security standards and policies, the university requires standard HTTP security headers on all Boise State web sites and web applications hosted on the university’s network, and all third-party affiliated web sites and web applications not hosted by the university.

There is a remote possibility that some HTTP security headers may adversely impact a web site or application (e.g., Content-Security-Policy may not work with certain WordPress sites). In any case, as many security headers should be added as possible.

Test Your Website

You can view the specific headers your web site or application lack by visiting securityheaders.com and entering your URL:

SecurityHeaders.com

Ideally all university web sites and applications should aim to achieve a grade of “B” or better.

HTTP Security Headers

Cache-Control Implementation

  • This field sets conditions for storing data in the browser cache. The cache-control header is defined in RFC-7234.
  • For cache-response verification, a no-cache directive is sufficient for a good response.

More information: Cache-Control (Mozilla developer resource)

Content-Security-Policy Implementation

  • Script source restrictions are inherited by the default-src value, which does not contain an “unsafe” keyword or a broad wildcard source.
  • Frame embedding is restricted.

  • A form-action directive is in place.

  • A valid reporting endpoint is provided.

More information: Content-Security-Policy (Mozilla developer resource)

Expires Implementation

  • The Expires header is specified in RFC-7234 (section 5.3). The date format for the Expires header is defined in RFC-7231 (section 7.1.1.1). The date format strictly specifies GMT as the time zone.
  • Expired headers must either have a value that’s an integer less than or equal to zero or contain a valid date in the format specified by RFC-7231.

More information: Expires (Mozilla developer resource)

HSTS (Strict Transport Security) Implementation

  • The max-age parameter is required.
  • The includeSubDomains and preload parameters are optional. If present, we check to see if they are legitimate and that there are no associated values (i.e., syntax parsing).
  • An HSTS header on an HTTP response is ignored.

More information: Strict-Transport-Security (Mozilla developer resource)

X-Content-Type-Options Implementation

  • Concatenate all the X-Content-Type-Options headers together.
  • Set the X-Content-Type-Options header to “nosniff.”

More information: X-Content-Type-Options (Mozilla developer resource)

Set-Cookie Implementation

  • <cookie-name>=<cookie-value>: The cookie name have to avoid this character ( ) @, ; : \ ” / [ ] ? = { } plus control characters, spaces, and tabs. It can be any US-ASCII characters.
  • Expires=<date>: It is an optional directive that contains the expiry date of the cookie.
  • Max-Age=<non-zero-digit>: It contains the life span in a digit of seconds format, zero or negative value will make the cookie expired immediately.
  • Domain=<domain-value>: This directive defines the host where the cookie will be sent. It is an optional directive.
  • Path=<path-value>: This directive define a path that must exist in the requested URL, else the browser can’t send the cookie header.
  • SameSite=Strict|Lax|none: This directives providing some protection against cross-site request forgery attacks.

More information: Set-Cookie (Mozilla developer resource)

General Resource Links

Back To Top