Security Kit
Provides Drupal with various security-hardening options through HTTP headers to mitigate risks from Cross-site Scripting (XSS), Cross-site Request Forgery (CSRF), Clickjacking, and improve SSL/TLS security.
seckit
Install
composer require 'drupal/seckit:^2.0'
Overview
Security Kit is a comprehensive security module that enhances the security posture of your Drupal website by implementing various HTTP security headers and browser-side protections. It provides a centralized configuration interface to manage multiple security mechanisms without requiring manual server configuration.
The module implements Content Security Policy (CSP) headers to control which resources browsers are allowed to load, preventing many XSS attacks. It supports X-Frame-Options and JavaScript-based clickjacking protection to prevent your site from being embedded in malicious frames. HTTP Strict Transport Security (HSTS) forces browsers to use HTTPS connections, while Certificate Transparency (Expect-CT) helps detect fraudulently issued certificates.
Additional features include Origin header validation for CSRF protection, Referrer-Policy headers to control referrer information leakage, Feature-Policy headers to restrict browser features, and the ability to disable autocomplete on login forms to prevent credential exposure. The module also provides a built-in CSP violation reporting endpoint for monitoring policy violations.
Features
- Content Security Policy (CSP) headers with comprehensive directive support including default-src, script-src, style-src, img-src, and more, with optional vendor-prefixed headers for legacy browser support
- X-XSS-Protection header configuration to control browser XSS filtering behavior
- X-Frame-Options header (SAMEORIGIN, DENY, ALLOW-FROM) for clickjacking prevention
- JavaScript + CSS + Noscript clickjacking protection that hides page content when displayed in unauthorized frames
- HTTP Strict Transport Security (HSTS) with configurable max-age, subdomain inclusion, and preload support
- Certificate Transparency (Expect-CT) header with enforce mode and violation reporting
- Feature-Policy header to control access to browser features like camera, microphone, and geolocation
- From-Origin header for additional cross-origin protection
- Referrer-Policy header with multiple policy options to control referrer information exposure
- CSRF protection through Origin header validation with configurable whitelist
- Login form autocomplete disabling to prevent credential caching
- Built-in CSP violation reporting endpoint at /report-csp-violation that logs violations to Drupal's watchdog
- Report-only mode for CSP to test policies without enforcement
Use Cases
Implementing Content Security Policy for XSS prevention
Enable CSP to whitelist trusted resource sources. Start with report-only mode to identify resources that would be blocked, then review logs at /admin/reports/dblog. Configure directives like script-src 'self' to only allow scripts from your domain. Gradually tighten the policy by removing 'unsafe-inline' and using nonces or hashes for inline scripts.
Preventing clickjacking attacks
Enable X-Frame-Options with SAMEORIGIN or DENY to prevent your site from being embedded in frames on malicious sites. For sites that need to be embedded by specific partners, use ALLOW-FROM with the partner's origin. Enable the JavaScript + CSS + Noscript protection for defense-in-depth against clickjacking.
Enforcing HTTPS with HSTS
After ensuring your site works correctly over HTTPS, enable HSTS with a short max-age initially (e.g., 300 seconds). Test thoroughly, then increase max-age to 31536000 (1 year). Enable includeSubDomains if all subdomains support HTTPS. Only enable preload after confirming the site will always be HTTPS and submit to hstspreload.org.
Monitoring security policy violations
Enable CSP in report-only mode with the default /report-csp-violation endpoint. Violations are logged to Drupal's watchdog. Review logs regularly to identify legitimate resources being blocked and potential attack attempts. Use external reporting services by configuring a custom report-uri for production monitoring.
Protecting sensitive forms from credential theft
Enable the autocomplete disabling feature to prevent browsers from caching usernames and passwords entered on login and registration forms. This is particularly important for shared computers or public terminals.
Controlling referrer information exposure
Enable Referrer-Policy with strict-origin-when-cross-origin to prevent leaking full URLs to external sites while maintaining referrer information for same-origin requests and analytics. Use no-referrer for highly sensitive sites where URL paths might contain sensitive information.
Tips
- Start with report-only mode for CSP to understand what would be blocked before enforcing the policy
- Use browser developer tools (Network tab, Console) to verify security headers are being sent correctly
- Test X-Frame-Options by attempting to embed your site in an iframe on a different domain
- Keep HSTS max-age low initially when testing, then increase to at least 1 year for production
- The 'unsafe-inline' CSP directive significantly weakens protection - try to eliminate inline scripts and styles
- Consider using CSP nonces or hashes instead of 'unsafe-inline' for necessary inline scripts
- Review CSP violation logs regularly to detect potential attacks and identify legitimate resources that need whitelisting
- Feature-Policy is being replaced by Permissions-Policy in newer browsers - monitor browser support
- Test security headers using online tools like securityheaders.com or Mozilla Observatory
Technical Details
Admin Pages 1
/admin/config/system/seckit
Central configuration page for all Security Kit security features. Allows administrators to enable and configure various HTTP security headers and browser-side protection mechanisms to harden the Drupal installation against common web vulnerabilities.
Permissions 1
Troubleshooting 6
Enable CSP in report-only mode first by checking the 'Report Only' option. Review CSP violation reports in Drupal logs at /admin/reports/dblog to identify which resources are being blocked. Add legitimate resource sources to the appropriate directives (script-src, style-src, etc.). Common issues include inline scripts requiring 'unsafe-inline' or third-party resources needing explicit origin allowlisting.
If your site needs to be embedded in iframes on specific external sites, change X-Frame-Options from DENY to ALLOW-FROM and specify the allowed origin. Note that ALLOW-FROM only supports a single origin. For multiple origins, consider using CSP frame-ancestors directive which supports multiple values.
Ensure max-age is at least 31536000 seconds (1 year), includeSubDomains is enabled, and the HSTS header is served from the root domain over HTTPS. Submit your domain to hstspreload.org only after confirming these requirements and that all subdomains support HTTPS.
Verify the report-uri is set to /report-csp-violation (the default). Ensure your site is accessible at this path. Check that CSP is enabled (either enforced or report-only). For cross-origin reports, ensure the reporting endpoint accepts the request by checking server logs.
Add the legitimate origin to the 'Allowed Origins' whitelist. Format should be the full origin including protocol (e.g., https://trusted-site.com). Ensure there are no trailing slashes in the whitelist entries.
Verify the module is enabled and configured. Check if a reverse proxy or CDN is stripping headers. Some hosting environments may override or remove security headers. Use browser developer tools (Network tab) to inspect actual response headers.
Security Notes 8
- All security features are disabled by default to prevent breaking site functionality - enable features consciously after testing
- The 'administer seckit' permission is marked as 'restrict access' and should only be granted to highly trusted administrators
- CSP can break site functionality if misconfigured - always test in report-only mode first
- HSTS with preload is difficult to undo - only enable after confirming permanent HTTPS commitment
- X-Frame-Options ALLOW-FROM is deprecated in modern browsers - use CSP frame-ancestors for better support
- The Origin header CSRF check may not work with all browsers - it's defense-in-depth, not a primary CSRF protection
- Disabling autocomplete may conflict with password managers - consider user experience implications
- Some security headers may be overridden by server configuration or reverse proxies - verify actual headers sent