Developer Hooks for Security in Statamic 6

Introduction

Security in a CMS isn’t just about user permissions or login rules — it’s about knowing what’s happening under the hood.
Statamic 6 gives developers more control than ever through events and hooks that let you observe, log, and even intercept what happens across the system.

Whether you’re building for clients with strict compliance needs or simply want more transparency over user actions, Statamic’s extensibility makes it easy to implement custom policies, audit trails, and alerts.

Hooks and Events — the Foundation of Extensibility

Statamic 6 continues to expand its extension layer in two ways:

• Events let you listen to what happens in the application and respond with your own logic.
  They use Laravel’s event system under the hood, so you can register listeners in your EventServiceProvider.
  → Statamic Docs: Events
• Hooks let you intercept or modify behavior within Statamic’s PHP flow — for example, during form submission or entry rendering.
  → Statamic 6 Docs: Hooks

Together, they provide the flexibility to inject custom security logic without touching the core.

Security-Relevant Events and How to Use Them

Several existing and upcoming events in Statamic 6 are directly relevant for security and auditing.
Here are a few key areas where you can integrate safely:

User Management

• UserSaved / UserDeleted — log or alert when user data changes.
  Useful for audit trails or invalidating related tokens.
  (See these event classes referenced in the Statamic REST API docs.)

Content Changes

• EntrySaving / EntryCreated / EntrySaved — run custom validation or record what was changed and by whom before saving.
  (Entry events in docs)

Forms

• FormSubmitted / SubmissionCreated — add anti-spam validation, trigger webhooks, or log potentially malicious input.
  (Example in the technical article on forms)

Assets

• AssetUploaded — automatically scan or sanitize uploaded files, or apply file policies.
  (Example usage appears in community code references and issue threads.)

Impersonation

• Statamic 6 adds deeper event coverage around impersonation — according to the roadmap item “Fire More Events”.
  This lets you log or send notifications when an admin impersonates another user.
  Impersonation can be restricted via the permission “impersonate users” (see v6 docs).

Elevated Sessions

• New in v6: Elevated Sessions (similar to “sudo mode”) require re-authentication before sensitive actions such as editing 2FA or managing roles.
  (Sneak Peek blog)
  You can extend this concept in your own code to protect custom routes.

Two-Factor Authentication

• Built into the v6 core — 2FA is now a first-class feature.
  You can listen to user update events to log or enforce 2FA setup policies.
  (Statamic 6 2FA documentation)

Example: Enforcing Security on Entry Publishing

You can intercept entry saves and prevent publication unless certain security rules are met:

// app/Listeners/EnforceSecurityPolicyOnEntries.php
namespace App\Listeners;

use Statamic\Events\EntrySaving;

class EnforceSecurityPolicyOnEntries
{
    public function handle(EntrySaving $event)
    {
        $entry = $event->entry;

        if ($entry->published() && !auth()->user()?->hasPermission('publish_sensitive')) {
            throw new \RuntimeException('Publishing blocked by security policy.');
        }
    }
}

Register the listener in your EventServiceProvider:

// app/Listeners/AuditUserChanges.php
namespace App\Listeners;

use Statamic\Events\UserSaved;

class AuditUserChanges
{
    public function handle(UserSaved $event)
    {
        \Log::info('User updated', [
            'user_id' => $event->user->id(),
            'by' => auth()->id(),
            'ip' => request()->ip(),
            'time' => now(),
        ]);
    }
}

This approach allows you to enforce organization-specific rules without modifying the CMS itself.

Example: Logging User Updates

A simple listener can record user changes for auditing:

// app/Listeners/AuditUserChanges.php
namespace App\Listeners;

use Statamic\Events\UserSaved;

class AuditUserChanges
{
    public function handle(UserSaved $event)
    {
        \Log::info('User updated', [
            'user_id' => $event->user->id(),
            'by' => auth()->id(),
            'ip' => request()->ip(),
            'time' => now(),
        ]);
    }
}

This ensures that every account modification leaves a trace — a useful foundation for audit trails or compliance reports.

Example: Guarding Against Suspicious Form Submissions

// php please make:listener GuardNewsletter --event=FormSubmitted
namespace App\Listeners;

use Statamic\Events\FormSubmitted;

class GuardNewsletter
{
    public function handle(FormSubmitted $event)
    {
        if ($event->form->handle() === 'contact' && $this->looksSuspicious($event->submission)) {
            \Log::warning('Suspicious form submission', ['ip' => request()->ip()]);
        }
    }

    protected function looksSuspicious($submission)
    {
        return str_contains($submission->get('message'), 'http://');
    }
}

This pattern is simple but powerful — it lets you react in real time when data looks unsafe.

Elevated Sessions in Practice

Statamic 6’s elevated session concept can be extended to your own features.
For example, if your site allows exporting private data, you could:

• Check whether auth()->user()->last_elevated_at is recent.
• If not, redirect the user to a re-authentication form.
• Only proceed once the elevated state is confirmed.

It’s a lightweight way to protect sensitive actions without requiring external packages.

JavaScript Hooks in the Control Panel

For front-end logic within the Control Panel, Statamic offers JavaScript hooks.
These let you show warnings, disable buttons, or adjust interface data when certain security conditions are met — for example, when impersonation mode is active.
(v6 docs: JavaScript Hooks)

Best Practices for Security-Driven Development

1. Log key actions such as user changes, impersonation, and entry publication.
2. Require re-authentication for your own sensitive routes, not just the built-in ones.
3. Keep dependencies minimal — use Statamic’s core 2FA and hooks instead of external packages.
4. Integrate with monitoring tools — forward events to your existing logging or alerting systems.
5. Review new v6 events regularly — Statamic is expanding event coverage to make this even easier.

Closing Thoughts

Statamic 6 isn’t just improving performance and UI — it’s making extensibility part of its security model.
By combining Laravel’s event system with Statamic’s custom hooks, developers gain full control over how authentication, content changes, and user actions are handled.

If you take advantage of these new hooks, you’re not just securing your projects — you’re building a CMS that’s aware, auditable, and ready for enterprise-grade needs.