Weave Code
Statamic Alpine Csp Forms Laravel Package
uams-web/statamic-alpine-csp-forms
A Statamic addon that makes Alpine.js forms work under a strict Content Security Policy. Build forms in Antlers that submit without inline handlers or unsafe-eval, using CSP-safe external scripts and nonces so you can keep headers locked down.
Statamic add-on with a form JavaScript driver that works under a Content Security Policy without 'unsafe-eval', using the @alpinejs/csp build.
Frequently asked questions about Statamic Alpine Csp Forms
- How do I install statamic-alpine-csp-forms in a Laravel Statamic project?
- Install it with Composer, then register or publish the Statamic add-on according to its README and swap the form driver so Statamic forms use the CSP-safe Alpine integration. You also need to load Alpine's CSP build instead of the default Alpine build. Because the package is pre-1.0, pin an exact version rather than using a floating constraint and read the changelog before upgrading.
- Does this package eliminate unsafe-eval and unsafe-inline from my Content Security Policy?
- The add-on is designed to let Alpine.js-powered Statamic forms work under a strict CSP without relying on unsafe-eval or unsafe-inline, using external scripts and nonces instead. The overview says inline expressions and x-* directives are bridged so dynamic forms can run under hardened headers. Before committing, confirm the exact required CSP directive set with the maintainer, because the public documentation does not state whether unsafe-eval is fully eliminated or only reduced.
- Which Laravel, Statamic, PHP, and Alpine.js versions does this addon support?
- At v0.1.0 there is no stated compatibility matrix for Statamic, Laravel, PHP, Alpine.js, or the Alpine CSP build, which is the biggest adoption unknown. Ask the maintainer for explicit version ranges before scheduling a spike. In the meantime, pin exact Composer versions and test against the specific Statamic and Alpine builds your application uses.
- Will my existing Statamic form tag and Antlers templates keep working with this addon?
- The package is described as working with Statamic's form tag and submissions, and it provides Alpine components for validation and interactivity. However, the code was extracted from one institution's site, so it may carry undocumented assumptions about specific fieldtypes, condition operators, or markup. Verify your actual Antlers forms and fieldtypes in a staging environment rather than assuming drop-in parity.
- How does client-side conditional field logic stay in sync with Statamic's server-side validation?
- The add-on includes a browser-side field-conditions evaluator, while Statamic also evaluates conditions server-side in PHP, so conditional logic exists in two places. That duplication is the central architectural risk because divergence can be silent and data-affecting, such as fields shown or hidden incorrectly at submission time. Ask the maintainer whether there is a divergence test that asserts client and server evaluators agree across a fixture set of conditions.
- What happens if Alpine.js or the CSP-safe form driver fails to load or is blocked?
- Graceful degradation is not verified in the available information, and a CSP-safe driver still depends on JavaScript executing. If the script is blocked by policy, fails to load, or throws an error, it is unclear whether forms fall back to showing all fields or hide fields and risk data loss. Test this deliberately with JavaScript disabled, a blocked script, and an intentionally broken CSP before relying on the add-on in production.
- Is this addon useful if my Laravel Statamic site already has a permissive CSP?
- If your current CSP allows Alpine's default build, this package adds a dependency without buying you much because its value is specifically avoiding unsafe-eval and unsafe-inline. The use case is genuine for public-sector, university, and audit-driven sites where strict CSP without unsafe-eval is a finding. Skip it unless strict CSP is an actual requirement or you are actively removing inline script allowances.
- Can I safely use a ^0.1 Composer constraint for production?
- No, ^0.1 is not a safe constraint for this package at its current stage. The release notes explicitly declare breaking changes on minor releases, even though the maintainer commits to leading each breaking change with the required action. Pin an exact version and read every changelog entry before upgrading.
- How should I test that client-side and server-side form conditions behave identically?
- Build a fixture set of Statamic conditions and fieldtypes, submit forms in a browser, and compare which fields are visible with what the server-side validation reports. Include unsupported or edge-case condition operators to see whether the client evaluator fails open, fails closed, or logs a console error. Also ask the maintainer for test coverage and mutation-testing results, since a mutation-instrumented CI job alone does not prove behavioural parity.
- What is the maintenance and fork risk of adopting a single-institution Statamic addon?
- The package originates from UAMS with no indication of external contributors, so bus factor is a real concern. MIT licensing means you can fork it if it is abandoned, but forking a browser-side evaluator that must match Statamic's server-side condition logic is non-trivial. Before adopting, ask about the security disclosure process, supported-versions policy, and the intended 1.0.0 scope and timeline.
Weaver
How can I help you explore Laravel packages today?