Drupal security headers with Security Kit

Yes. Roll the policy out in report-only mode first, or stage it on a non-production copy, and collect violation reports from real browsing before you enforce anything. Headers such as a Content-Security-Policy break scripts, styles and embeds that teams forgot about, and the failures often appear only on admin pages or in logged-in workflows. Walk through the main content types, the editor screens, search, forms and any checkout or login path, and record each blocked resource. Enforce only after the list of violations is either fixed or deliberately allowed. Ask your team to repeat this check after every significant change to the theme, modules or third-party scripts.

Treat each exception as a named decision with an owner, a reason and a review date. Start by listing every embed and tool the site loads: video players, maps, analytics, chat widgets, consent banners, and admin utilities used by editors. For each one, record the exact origins or directives it needs and whether it is needed on all pages or only on some. Scope exceptions narrowly, so an admin-only tool does not weaken public pages, and avoid broad wildcards where a specific host will do. Where a vendor cannot be scoped tightly, document the residual risk and the compensating control. Keep this list in version control next to the policy so that removing a vendor also removes its allowance.

Keep the header configuration in code and in exported configuration, not in ad hoc settings edited in the admin interface on one server. Security Kit settings and any CSP rules should be exported with the rest of the site configuration, so they move through the same review and deployment path as code. After each core or contributed module update, compare the live response headers with the expected set, because an update can change defaults, add new modules that set their own headers, or revert a configuration import. Include header checks in the release checklist and in the regression tests your team already runs. Read the release notes for Security Kit and related modules before upgrading, since the Drupal core release schedule places security releases on a fixed Wednesday window and urgent updates may arrive with little lead time.

Monitor the headers that clients actually receive, at the edge, not only the values Drupal sends. A CDN, load balancer or reverse proxy can strip, override or duplicate headers, and a web server change can alter the order or presence of directives. Set up a scheduled check that requests key pages from outside your network and compares the returned headers against the expected policy, and alert on any difference. Include the paths that behave differently, such as cached pages, login redirects and file downloads, because they may be served by different layers. Ask your hosting or CDN team which layer owns each header, and document it, so that a change to one layer does not silently override another.

Record the policy as configuration and as a short document that explains each directive. The configuration file or exported settings show what the site does, while the document explains why each value exists, which feature needs it, who approved it, and when it was last reviewed. Store both in the same repository as the site code so that changes go through pull requests and leave an audit trail. Include the expected response headers for representative pages, the list of exceptions with owners, and the steps to roll back a change. This record gives auditors and security reviewers something concrete to examine, and it also gives your own team a way to tell whether a header change was intentional. DeployOpen can prepare this documentation as part of a scoped engagement, but the controls remain your responsibility to operate.

No. Security headers reduce the browser-side impact of some attacks, such as clickjacking, certain cross-site scripting paths and some framing or content-type abuse, but they do not fix vulnerable code, weak access control or unpatched modules. A Content-Security-Policy that blocks inline scripts still cannot protect a page from a flaw in a trusted script it allows, and a frame restriction does nothing against an API that accepts unauthenticated requests. Keep headers as one layer alongside timely security updates, access control, input handling and security testing. When you present the policy internally, describe what each header addresses and what it does not, so that nobody assumes a header covers a gap elsewhere.

Ownership should sit with a named team that can approve changes, usually a combination of the Drupal development lead, the platform or hosting team that controls the web server and CDN, and a security reviewer. Ongoing cost comes from reviewing exceptions when vendors change, testing after updates, and watching for drift, so it recurs with every release cycle rather than being a one-time task. The main drivers are how many third-party tools the site loads, how often the site is updated, and whether headers are set in several layers. Ask any partner for a quote that separates the initial policy build and testing from the recurring review and monitoring, and confirm who performs each task.

Effort depends on how many sites, web server layers and CDN layers set headers, and how many embeds and admin tools must keep working. A single Drupal site with headers set in one place is a small change. A multisite estate with Nginx, a CDN and third-party embeds needs a mapping exercise, a report-only rollout and a sign-off cycle for each layer. No duration is given here. Ask any partner to show the effort split across discovery, configuration, testing and handover, and to name which items are one-time and which recur on each Drupal release.

The main cost drivers are the number of sites and hosting layers, the number of third-party scripts, frames and embeds that need allowances, and how many people must approve policy decisions. Recurring costs come from re-testing after Drupal security releases, which are published on the third Wednesday of the month, and from reviewing new embeds added by content teams. Ask for a written quote that lists each site, each layer that sets headers, the testing method, the number of review rounds and any ongoing retainer for policy upkeep.

You need administrative access to the web server configuration, the CDN or edge rules, and the Drupal configuration for the Security Kit module. Staging environments that match production headers are important, because a header that works on staging can break a live embed. You also need named owners who can decide on frame embedding, inline script policy and third-party domains. Without those decisions, the work stalls at the point where a header would block a feature. Confirm these owners and access paths in writing before a quote is accepted.

Yes, if your team has Drupal experience, control of the web server and CDN, and time to test. Drupal teams that already run updates and configuration exports usually handle the Security Kit module without outside help. The harder part is the policy work: deciding which origins may frame the site, which scripts may run, and how a header change is rolled back. Teams without a clear owner for those decisions, or without a staging copy, often choose outside help for the first rollout and then run the maintenance themselves.

No. Headers reduce the exposure to clickjacking, cross-site scripting and some CSRF paths, and a scanner will often report their absence. However, a scanner passing does not prove the site is secure, and an auditor will want to see the headers, the reasoning behind each value, the test evidence and the change records. Headers also do not fix vulnerable code, weak passwords or outdated contributed modules. Treat headers as one control within a wider program, and ask any assessor which evidence they expect before you scope the work.

Set each header in the layer that controls the response, and avoid setting the same header in two layers with different values. Security Kit can set headers from Drupal, but responses served by a CDN or a static asset path may bypass Drupal entirely. Check the final response headers from outside your network after each change, because duplicated or conflicting headers are a common fault. Confirm with your Drupal and web server vendors which layer owns each header.

Ask for the sites and layers in scope, the list of headers to set and the reason for each value, the method for testing headers from outside the network, and the number of staging and production change windows. Ask who approves policy decisions, how rollback works, what documentation you receive and how the work handles future Drupal core and contributed module updates. Ask whether ongoing retainers cover re-testing after security releases. Because DeployOpen works to a written scope, a clear list of these items is what allows a fixed-scope quote.