Weave Code
Twig Sandbox Bundle Laravel Package
intaro/twig-sandbox-bundle
Symfony bundle integrating Twig's sandbox extension to safely render untrusted templates with configurable security policies, allowed tags, filters, functions, and methods. Ideal for user-supplied templates.
Annotation configuration of the allowed methods and properties for Twig_Sandbox extension
Frequently asked questions about Twig Sandbox Bundle
- What is intaro/twig-sandbox-bundle and what problem does it solve?
- It is a Symfony bundle that integrates Twig's Sandbox extension using a configurable SecurityPolicy, so you can render templates authored by untrusted users without exposing arbitrary PHP methods, tags, or filters. You define allowlists for tags, filters, functions, methods, and properties, and anything outside those lists throws a security error at render time. It targets use cases like user-editable content blocks, customer-supplied email templates, and low-code template surfaces.
- Can I install intaro/twig-sandbox-bundle in a Laravel application?
- No. It is a Symfony bundle, not a Laravel package: it registers through the Symfony kernel, ships a dependency-injection compiler pass, and builds its allowlist by scanning Doctrine annotations against Symfony service metadata. Laravel has no bundle or compiler-pass mechanism, so the entry point is structurally unusable there. Composer may resolve the code, but nothing in a Laravel app will bootstrap or configure it.
- How do I sandbox untrusted Twig templates in Laravel then?
- The sandbox itself is core Twig, so you only need to wire it up yourself. Add Twig alongside Blade via rcrowe/twigbridge, construct a Twig\Sandbox\SecurityPolicy explicitly with your allowed tags, filters, functions, methods, and properties, and attach Twig\Extension\SandboxExtension with that policy to the sandboxed environment. Then enable the sandbox on the environment used for user templates and cache the compiled policy at build time instead of rebuilding per request.
- Which Laravel versions does this package support?
- None, because it is not a Laravel package. There is no service provider, no publishable config file, and no Laravel version constraint in its composer.json. Its compatibility surface is Symfony framework versions plus the Twig version it depends on, which is irrelevant if you are building on Laravel. In a Laravel app you would pin twig/twig and your Twig bridge yourself and manage the SecurityPolicy in your own code.
- How do you configure allowed tags, filters, methods, and properties with this bundle?
- The bundle maps allowlist entries onto Twig's SecurityPolicy setters such as setAllowedTags, setAllowedFilters, setAllowedMethods, and setAllowedProperties, with the source of those entries being bundle configuration and Doctrine annotations on the classes you expose. The concept is portable to Laravel even though the wiring is not. In Laravel you would replace the annotation scan with native PHP 8 attribute reflection over an explicit namespace list, or just hardcode the allowlist in a dedicated policy class for maximum auditability.
- What is strict mode in version 3.4.0 and is it on by default?
- Version 3.4.0 adds a strict-mode validator that checks the sandbox configuration for completeness, and its natural home is the same compiler pass that builds the allowlists. The release note is a single line with no documentation of what strict actually enforces, whether it is opt-in or default, and whether it fails the build or only warns. If it is default-on, that is a behavior change in a minor version bump; verify against the source before relying on it. For a Laravel port, the useful takeaway is the idea of a build-time gate that fails CI when a public method in a sandboxed namespace has no explicit policy entry.
- Is an annotation-driven security policy a good idea?
- It is a known weak point: the security boundary ends up scattered across docblocks or attributes instead of one auditable config file, and a missing or misspelled annotation silently changes the allowlist. Strict mode exists precisely because of that failure mode, which confirms the risk is real. Doctrine annotations are also in maintenance mode, so an annotation-only integration inherits a dead-end dependency. Prefer an explicit policy object or PHP 8 attributes combined with a CI check that rejects unannotated public methods in sandboxed namespaces.
- Is this package safe to depend on in production?
- The capability it wraps is security-critical, and this artifact has very little downstream validation: roughly 7 stars, 0 dependents, a single maintainer, and a release cadence of one PR at a time. The 3.4.0 release is a sign of life rather than evidence of hardening, with no external review or published test coverage. None of that makes the underlying Twig sandbox unsafe, but it does mean you should not treat this bundle as an audited boundary. Build and test your own policy rather than inheriting one from a lightly used dependency.
- What are the alternatives for safely rendering untrusted templates in Laravel?
- The primary alternative is using Twig's built-in Sandbox extension directly with your own SecurityPolicy and SandboxExtension wiring, which removes the third-party configuration layer entirely. If you want to stay on Blade, you generally need a different strategy such as a restricted expression evaluator or a whitelisted rendering component, since Blade was not designed as a sandbox. Avoid anything that evaluates user PHP, and be cautious with packages like this one that cannot be bootstrapped outside Symfony.
- How should I test that my sandbox policy actually blocks dangerous templates?
- Write tests that render deliberately hostile templates and assert that Twig raises SecurityNotAllowedTagError, SecurityNotAllowedFilterError, SecurityNotAllowedMethodError, or SecurityNotAllowedPropertyError as appropriate. Cover include and embed of arbitrary paths, attribute access on objects, static and magic method calls, and any custom functions you registered. Run those tests as a CI gate alongside a completeness check that fails the build when a public method in a sandboxed namespace is missing from the allowlist. Finally, verify the sandbox is enabled on the correct environment, since a misconfigured environment silently renders unsandboxed.
Weaver
How can I help you explore Laravel packages today?