Security Freeze

AI Development Declaration

This module was written by AI agents. The module maintainer reviews and takes full responsibility for all the work done by AI.

About the Module

A read-only "security maintenance mode" for Drupal. Keep your public-facing site live and browsable while locking down all writes, logins, and file changes during a security incident — or while assessing and deploying a security patch.

What is it for?

When a critical vulnerability is disclosed or your site is under active threat, you need to lock things down fast — but taking your site totally offline should be the last option, not the only option.

Security Freeze solves this by putting your Drupal site into a read-only mode at the application layer. Visitors can still browse pages, use search, and navigate menus. But nobody can log in (not even UID 1), no content can be written, and no files can be modified. The module is designed to work alongside a read-only database, turning what would be ugly 500 errors into clean 403 (Access Denied) responses. Because your site never returns 500 errors, it stays "online" from the perspective of uptime monitors and health checks.

There is no web UI — everything is operated over SSH using Drush commands (drush freeze:on / freeze:off / freeze:status) or via settings.php. This is intentional: during a security incident, SSH may be the only safe access channel.

Features

• Blocks all logins — cookie sessions, HTTP basic auth, bearer tokens, and all active sessions are terminated. UID 1 cannot log in.
• Blocks all database writes — multiple independent layers (statement-level guard, service-level takeover, optional frozen database driver) refuse every INSERT, UPDATE, DELETE, and DDL statement through Drupal's database API.
• Blocks file uploads and destructive file operations — uploads are stopped before the file reaches disk; move, rename, delete, and chmod on existing files are refused.
• Blocks JSON:API and REST writes — unsafe HTTP methods against decoupled API endpoints return a clean 403.
• Blocks cron — web-triggered, automated, and CLI drush cron are all stopped.
• Keeps read-only pages live — page views, Views, search, facets, exposed filters, and menus continue working normally.
• Enforces a strict Content-Security-Policy — a self-host-only CSP header is set on every response while frozen, with no dependency on any other module. The policy is customisable or can be skipped entirely.
• Redirects logging to stderr — the database logger is suppressed; log entries go to stderr so your audit trail continues without database writes.
• Handles multilingual sites — translation writes on render are silently dropped so translated pages still display correctly.
• Handles state and key/value writes — Drupal's lazy state writes on read requests are dropped in-memory so pages don't crash on a read-only database.
• Static homepage generation — optionally generates and serves a static index.html to minimise server load during the incident.
• Defense-in-depth — every security control uses multiple independent layers, so bypassing one still meets the next.

What you must do at the infrastructure layer

This module blocks writes at the Drupal application layer, but the database server itself is the final guarantee. You must:

1. Move cache, lock, and flood off the database — use Redis, Memcached, or another external backend. If these services remain on the database, the first cache miss on a read-only database will crash the site. The freeze:on command runs a preflight check and warns you if any are still database-backed.
2. Set the database server to read-only — after running drush freeze:on, set read_only = ON (and super_read_only = ON on MySQL/Aurora) on your database server. This is the un-bypassable backstop that stops even a direct PDO exploit.
3. (Optional) Mount the application codebase read-only — the module guards file operations through Drupal's API and PHP stream wrappers, but to stop raw filesystem writes from an exploit, mount the application codebase read-only at the container or volume level. Note that sites/default/files should remain writable, as Drupal needs it to generate aggregated CSS/JS files, image style derivatives, and other runtime assets.

More information

For full documentation — including the freeze/unfreeze procedure, configuration options, the cache trap, database driver setup, and how each security layer works — see the README included with the module.

Requirements: Drupal 10.3+ or 11. No contrib dependencies.