Announcing Stott Security Version 3.0
I'm proud to announce the release of version 3 of Stott Security for Optimizely PAAS CMS. This release has been developed over several months owing to a significant new feature among other quality of life changes.
Permissions-Policy Support
The Permissions-Policy HTTP header (formerly Feature-Policy) allows developers to control which web features and APIs can be used in the browser, and by which origin. This header can improve security and performance by restricting access to sensitive capabilities such as the camera, microphone, and geolocation.
Currently, support for the Permissions-Policy header is mixed. It is well-supported by Chromium-based browsers like Chrome and Edge, but not yet implemented in Firefox or Safari. This naturally raises the question: why invest time in implementing a feature that isn’t universally supported?
According to the latest browser market share data, over 70% of users are on browsers that support this header. Additionally, unsupported browsers simply ignore the header, without causing any issues. While I've yet to see a penetration test flag the absence of this header as a vulnerability, I’m increasingly seeing clients request its inclusion as part of their CMS security requirements.
To support this, I’ve added a new Permissions Policy screen to Stott Security. This interface allows administrators to enable or disable the Permissions-Policy header globally with a single toggle. It also includes a filter bar for quickly narrowing directives by source (URL) or current configuration (e.g., *Disabled*, *Allow None*, *Allow All Sites*, etc.).
Clicking the Edit button for a directive opens a modal where the configuration for that specific directive can be adjusted.
Available options include:
- Disabled (Omitted this directive from the policy)
- Allow None
- Allow All Sites
- Allow Just This Website
- Allow This Website and Specific Third Party Websites
- Allow Specific Third Party Websites
For configurations involving third-party origins, administrators can specify one or more sources. Input is strictly validated to require only protocol and domain. Wildcards are supported, but only as the first segment after the protocol (e.g. https://*.example.com).
All changes to the Permissions Policy are fully audited. Additionally, import/export functionality has been extended to include this new feature.
Small Features
.NET 9 Support
Import Settings Tool
In previous versions, the import tool required that CSP, CORS, and Response Headers configurations all be present in the import file. To support backwards compatibility with export files created in version 2.x, validation in version 3.x has been relaxed. Now, settings are only applied if they contain a non-null value. This allows for partial imports; if your import file includes only the CSP configuration, then only the CSP settings will be updated, leaving all other settings unchanged.
X-XSS-Protection Header Warning
X-XSS-Protection: 1; mode=block, malicious actors could exploit it to trigger denial-of-service conditions by injecting scripts that caused legitimate content to be blocked. Alternatively, when simply enabled without blocking (X-XSS-Protection: 1), the header became susceptible to XS-Search attacks this is where an attacker submits crafted XSS payloads to probe for differences in application behavior, potentially exposing sensitive data in applications that would otherwise be considered secure.Content Security Policy Source Updates
Validation has been enhanced to support the 'inline-speculation-rules' keyword within Content Security Policy (CSP) directives. Speculation rules enable the browser to preload potential navigation targets based on user behavior, improving perceived performance by initiating page loads slightly before user interaction (e.g., clicks).
The CSP Edit Source modal in Stott Security has also been updated to ensure that special keywords such as 'unsafe-inline', 'unsafe-eval', and 'inline-speculation-rules' can only be added to directives where they are valid. These are typically limited to script-src, style-src, and their more specific variants.
CMS Editor Gadget Removed
In version 2, I introduced a CMS Editor gadget that displayed the HTTP headers generated when rendering a specific page. This was intended to support the feature allowing users to extend the Content Security Policy (CSP) for individual content items by specifying additional sources.
However, over time it became clear that this approach had several drawbacks:
- The gadget was read-only and appeared automatically for all CMS administrators, even if the page-specific CSP feature wasn't in use. In most cases, this meant the gadget was visible but offered little to no value.
- Some developers experienced installation issues with the AddOn. Specifically, in projects where the
.csprojexcluded themodules\_protectedfolder; often done to avoid conflicts with other third-party AddOns that add files to the solution multiple times. This resulted in the Stott Security module.config being be removed and not re-added. This in turn causes an error during the start up of the solution that could only be resovled by manually adding the into source control and project.
Given the minimal benefit provided by the gadget and the friction it caused in certain build pipelines, I’ve decided to remove it entirely in version 3.
Obsolete Code Removed
- SecurityServiceExtensions.AddCspManager(...)
- Replaced by SecurityServiceExtensions.AddStottSecurity(...)
- SecurityServiceExtensions.UseCspManager()
- Replaced by SecurityServiceExtensions.UseStottSecurity()
- CspReportingViewComponent
- Replaced by Report-Uri and Report-To within the CSP.
Report To Endpoint Fixes
application/csp-report. With the introduction of the report-to directive, browsers are now meant to send a collection of CSP Reports in an array with a content type of application/reports+json. The intent being to reduce the number of requests being made to any reporting endpoint.Get It Now
You can find all of my content collated on https://www.stott.pro/
Comments