Why you should consider implementing CSP and HSTS

Attention: Clients with active information security policies should implement the CSP and HSTS website security policies for their websites.

What is CSP? Content Security Policy (CSP) is an added layer of security that helps detect and mitigate certain types of website attacks that may be performed by malicious entities seeking to gain access to your website and/or web-based marketing technology applications.

What is HSTS? HTTP Strict Transport Security (HSTS) is a web security policy mechanism that helps mitigate certain types of website attacks to keep websites more secure.

Why this is important: Commercial websites and web applications are under attack more frequently than ever, and while RubensteinTech has numerous safeguards in place to protect against these attacks, it is critical to continue to upgrade and enhance your system’s website security. Neither CSP nor HSTS are particularly new standards, but they are now widely supported across modern web browsers and recommended to help prevent entire classes of attacks at the policy level. 

CSP protects against a number of potential attacks, including cross-site scripting (XSS), clickjacking, and data injection attacks, while HSTS prevents against protocol downgrade attacks and hijacking of cookies by declaring that web browsers only interact using HTTPS connections, which are secured via Transport Layer Security (TLS/SSL).

The bottom line: The consequences of not implementing CSP and HSTS can result in everything from data theft to site defacement to distribution of malware.

What can we do to be prepared? Unlike recent policy documentation updates required for CCPA, GDPR, and related data privacy compliance, CSP and HSTS are actually digitally-defined policies specified in code (specifically, HTTP Response Headers), which are defined within the web/application server and communicated electronically to all requestors. These headers explicitly declare which external systems can embed code and content in your website and web applications (e.g., embedding a Google Analytics tracking script or running code to load a licensed webfont).

RubensteinTech continuously upgrades our website protection and attack prevention measures across our network and all of our systems, but implementing these two policies requires project-specific review and implementation, preventing them from being applied without customization.

For CSP to be implemented, an audit of all third-party systems and embedded website content must be performed, and those content sources explicitly defined in the CSP protocol. You may perform this review and audit, and provide the results of that audit to RubensteinTech for implementation within your systems. We can also provide this service for you. If you have recently completed a cookie audit, we may be able to utilize that output, as many of those external cookies are set via external scripts and embedded content.

For HSTS, you would simply need to confirm that you intend to keep the current website serving securely via HTTPS and secured via Transport Layer Security (TLS/SSL). With that confirmation, the HSTS headers can be enabled for your front-end website and any RubensteinTech-managed web applications, services, blogs, and microsites.

In addition to conducting this review, we recommend bringing this matter to the attention of your Chief Security Officer and/or Chief Information Officer to determine what, if any, recommendations they have in pursuing this update. These policies are starting to be flagged by the leading security monitoring and systems scanning tools, so they are likely already aware of CSP and HSTS requirements for your organization.

What action will RubensteinTech take and when? Beyond the above, we recommend performing a thorough review of the third-party embedded code that may be used on your website. Current RubensteinTech clients can request RubensteinTech to perform such an audit and create a list of systems to be placed into your site’s Content Security Policy. We will configure those settings and create appropriate CSP and HSTS policy headers, following the documented standards for these protocols.

Note that with CSP, if additional systems are added or embedded into the website in the future, they will need to be specifically added to the CSP policy. Similarly, if systems are retired and no longer needed, they should be removed. For example, if the firm begins to embed Instagram posts on a website that did not previously allow Instagram content, the CSP must be updated. Similarly, if Instagram changes its server details or related information for display posts, or your organization decides to stop embedding such content in the website, the CSP policy should be updated to reflect these changing details.

Enabling HSTS for your website is generally straightforward, but does have a minimal chance of causing issues in the future if you should ever want to downgrade to HTTP-only web services. (This is no longer typically considered an option for data privacy and security reasons.)

What happens if we do nothing? Defining and implementing these new policy standards is completely optional, and is not required for visitors to access your website or for your users to access web-based marketing technology applications. Third-parties, clients, and/or internal security teams may have requirements dictating the use of CSP and HSTS to improve your overall online security posture, but they not currently required for successful operation of your website.

For more information on this matter, please visit the following:

—Mozilla.org on CSP
—Mozilla.org on HSTS
—Wikipedia on Content Security Policy
—Wikipedia on HTTP STS