Sensitive Form Fields for Statamic: Encrypt Submissions and Control Access

The hidden risk in “simple” website forms

Most teams treat contact forms as harmless: a name, an email address, a message. But the operational reality is different. Form submissions get copied into backups, exported to CSV, forwarded internally, and accessed by multiple Control Panel users. Over time, a simple inbox becomes a distributed data store of personal information.

This is where many projects become fragile. Even if you have HTTPS, even if you keep your server patched, the most common failure modes are still operational: overly broad access inside the admin panel, accidental exports, a compromised account, a leaked backup, or a staging environment that should never have had real submissions in the first place.

Sensitive Form Fields for Statamic addresses a specific part of that problem: it allows you to encrypt selected form fields at rest so that stored submissions are less useful if the storage layer is exposed. Add-on link: https://statamic.com/addons/isapp/sensitive-form-fields

What “encrypt at rest” actually gives you (and what it doesn’t)

Encryption at rest is a practical control: the sensitive values are stored in an encrypted form, and only decrypted when the application decides it is allowed. If a backup leaks or a file store is accessed directly, the encrypted values are not immediately readable.

It is not a magic shield against every scenario. Encryption at rest does not protect you if an attacker has full application access with permission to decrypt, or if your encryption keys are mishandled. In other words, it reduces the impact of certain classes of incidents, but you still need sensible access controls, logging, and secure operations.

How Sensitive Form Fields works in Statamic

The add-on is intentionally field-level rather than “encrypt everything.” You mark specific fields as sensitive in the form blueprint. When a submission is saved, those values are encrypted before being written to storage. When the submission is viewed in the Control Panel, the add-on decrypts (or masks) the values depending on permissions and configuration.

That field-level approach matters in real projects. If you encrypt every field, you typically lose useful workflows such as filtering, searching, and quick triage. With per-field encryption, you can protect what truly needs protection—often just a few fields like email, phone, and message—while keeping non-sensitive fields operational.

Free vs Pro: the difference is access control, not encryption

Both editions focus on encryption at rest. The practical difference appears when you have multiple Control Panel users or roles.

In the free edition, sensitive fields are stored encrypted, but they are generally shown decrypted in the Control Panel to logged-in users. This already reduces the risk of exposed storage (backups, file leaks), but it does not address the “too many people can read PII” problem.

In Pro, you can apply role-based visibility. Authorized users can view decrypted values, while unauthorized users see masked content. This is the control that brings the add-on closer to a “least privilege” model in daily operations.

Why role-based masking is a real operational win

Many teams underestimate how quickly admin access grows: marketing needs to edit content, support needs to handle inquiries, project managers need visibility, and contractors may need temporary access. Even if everyone is trusted, broad access increases risk: accounts get compromised, laptops get lost, credentials get reused, or the wrong person exports data “just to help.”

Masking sensitive fields for non-authorized roles is a straightforward way to reduce exposure without blocking work. People can still navigate submissions, triage, and route inquiries, but only the roles that genuinely need plaintext access can read it.

Key management: the part you cannot ignore

Encryption is only as reliable as your key management. In Laravel-based applications, encryption depends on APP_KEY. That means a few non-negotiable operational rules:

• Back up your APP_KEY securely. If you lose it, previously encrypted submission values cannot be decrypted.
• Do not rotate keys casually. Changing APP_KEY without a plan can make stored values unreadable.
• Treat staging carefully. Avoid copying production submissions into environments where keys and access controls are weaker.

If your organization requires key rotation, the Pro edition includes a re-key workflow designed for safe rotation: you can re-encrypt existing encrypted fields under a new key rather than losing access to historical submissions.

Limitations you should plan for

Field-level encryption introduces trade-offs. The key one is that encrypted data becomes opaque to search and filtering. If you encrypt an email field, you typically cannot reliably search submissions by email within storage because the stored value is encrypted. In practice, teams solve this by encrypting the “content” fields (message, phone) while keeping certain identifiers searchable, or by using alternative non-sensitive indexes depending on their needs.

Another practical limitation is field complexity. Many encryption-at-rest solutions work best on plain string fields. If your submission fields are complex nested structures, you should validate which parts are supported and adjust your blueprint accordingly.

A practical checklist for adopting sensitive field encryption

If you want this to deliver real risk reduction (not just a checkbox), keep it simple:

1. Identify the few fields that truly need encryption (often email, phone, message, and any free-text fields that may contain PII).
2. Define who should see plaintext in the Control Panel and apply least privilege (Pro makes this straightforward).
3. Document key handling: where APP_KEY is stored, how it is backed up, and who can rotate it.
4. Review exports and automations: decide whether masked or decrypted values should flow to external tools.
5. Audit environments: keep real submissions out of non-production setups unless you are sure access and keys are controlled.

With these steps, sensitive-field encryption becomes a practical improvement in security posture without turning the site into a compliance-heavy project.

Conclusion

Sensitive Form Fields for Statamic is a focused control for a common risk: form submissions that quietly accumulate personal data. By encrypting selected fields at rest—and by adding role-based masking in Pro—you can reduce the impact of storage exposure and limit who can view plaintext data inside the Control Panel.

Add-on link: https://statamic.com/addons/isapp/sensitive-form-fields