Security Laravel Package

Product Decisions This Supports

• Build vs. buy for security hygiene. The package bundles the unglamorous but mandatory primitives — input sanitization, context-aware output escaping (HTML, attribute, URL, JS, CSS), KSES/htmLawed tag filtering, and security headers — behind one facade and a set of global helpers. The PM decision this informs is whether to spend engineering weeks re-deriving Laminas Escaper + htmLawed wiring, or to take a dependency and spend that time on product surface. For most teams the answer favors buying, provided the dependency risk is acceptable (see below).
• A staged CSP rollout, which is a product decision, not just a security one. CSP enforcement breaks pages: inline scripts, third-party tags, analytics snippets, Livewire payloads. This package supports the rollout pattern that actually ships — nonce generation, a policy builder with Strict / Relaxed / Livewire presets, a violation reporting endpoint, a stored violation model, and a dashboard plus csp:stats / csp:prune. That sequence (report-only → observe real violations → tighten → enforce) lets a PM schedule CSP as a tracked workstream with data, rather than as a one-way ticket that produces a rollback.
• User-generated content features. Any roadmap item that accepts rich text — comments, bios, marketplace listings, CMS blocks, support macros — needs an allowlist filter and per-context escaping. KSES filtering plus the NoHtml / SecureUrl validation rules is a direct enabler for those features, and the allowlist is configurable, which means the product decision "what markup do we permit in a comment?" becomes a config change rather than a code change.
• Security evidence for sales and compliance. security:audit, security:scan, security:check-config, security:test-headers, security:scan-deps, and security:baseline, with report generators emitting JSON, HTML, JUnit, SARIF, and Markdown, are effectively a CI-gate and audit-evidence pipeline. This is the strongest PM-relevant asset in the package: it converts "we care about security" into artifacts you can attach to a SOC 2 control, a customer security questionnaire, or a pull-request check.
• Third-party script governance. The ap.security.csp.directives filter lets the host app mutate the directive array per request. That makes "marketing wants tag manager on checkout" a reviewable, centralized policy decision instead of an ad-hoc template edit.
• Ecosystem/modularity strategy. The 2.0 repackaging (core split from security-auth, rbac, secure-uploads, security-analytics, compliance, with a security-full meta-package) is a deliberate product decision by the maintainer in favor of composability. For a PM this is a scope signal: you can adopt the core narrowly today and defer auth/compliance suites, but each sibling you add deepens vendor lock-in to this ecosystem.

When to Consider This Package

Consider it when:

• The stack is Laravel 10–13 on PHP 8.2+ (8.3+ for Laravel 13) and you are already evaluating or using other ArtisanPack-UI packages — the shared hooks system (artisanpack-ui/hooks) only pays off inside that ecosystem.
• Your actual gap is CSP and security headers, not sanitization. Laravel already gives you Blade auto-escaping and e(); the marginal value here is nonces, policy presets, violation reporting, and security.headers middleware in one coherent unit.
• You want security checks in CI with machine-readable output (SARIF for code scanning, JUnit for test dashboards) and do not want to assemble that yourself.
• You have a named security owner who can review the extension hooks. The README is explicit that ap.security.sanitizedInput, ap.security.escapedOutput, and ap.security.ksesAllowedTags subscribers can weaken the guarantees the package provides. That is a governance requirement, not a footnote — treat those hooks as privileged, code-reviewed surface.
• You can pin to an exact version and absorb occasional breaking repackaging (1.x → 2.0 moved five capability areas out of the package).

Look elsewhere when:

• Bus factor and validation matter more than feature breadth. One GitHub star and zero dependents means no independent production validation, no community CVE-watching, no third-party battle testing. For a security dependency the risk is asymmetric: a defect in a sanitizer or escaper is materially worse than a bug in a UI component library. If you require an SLA, a security disclosure process with a track record, or vendor indemnity, choose an established option (spatie/laravel-csp, HTMLPurifier/mews/purifier, or framework primitives) or budget for internal review.
• You only need escaping and sanitization. Use Blade's escaping, e(), and Laravel's validation rules. Do not add a dependency for escHtml.
• You need authentication, 2FA, RBAC, uploads, or GDPR tooling. Those live in sibling packages; evaluating this one for them is a scope error. Note the sibling packages inherit the same adoption risk.
• You are not on Laravel, or you are on PHP < 8.2 / Laravel < 10.
• Release hygiene is a hard gate. Two changelog entries are worth putting in front of engineering: 2.0.1 restored a command that an over-broad export-ignore had stripped from the release tarball, breaking package discovery for every consumer; and 2.1.0 fixed sanitizeFloat() returning a string under a float return type — a TypeError that implies the method had essentially never been exercised. Neither is disqualifying given the 2026-07-21 release, but they argue for a spike with test coverage before wider adoption.

How to Pitch It (Stakeholders)

To executives: This is a security-controls package, not a feature. It gives us Content Security Policy with a report-only-to-enforce path, standard security headers, sanitization/escaping utilities, and — most usefully — audit commands that generate CI reports and audit-ready artifacts (SARIF, JUnit, HTML, Markdown). The business case is cost avoidance and evidence: we get a documented, reproducible security posture story for customer questionnaires and compliance reviews without building the tooling ourselves. It is MIT-licensed, so there is no procurement or per-seat cost. Caveat to state plainly: it is early-stage with a single-maintainer profile and no measurable adoption, so I recommend a scoped pilot (CSP + headers middleware + audit commands in CI) rather than an org-wide mandate, with a documented exit path to spatie/laravel-csp or framework primitives if the project stalls.

To engineering: Thin, conventional Laravel package — service provider, Security and Csp facades, global helper functions, config publish via vendor:publish --tag=security-config, and route middleware (csp, security.headers, xss.protection, api.security, api.rate_limit). Escaping is Laminas Escaper-backed; KSES is htmLawed-backed; both are known quantities rather than bespoke implementations, which is the right call. CSP adds a nonce Blade directive, three policy presets including a Livewire-aware one, a violation reporting endpoint with a CspViolationReport model, and Artisan commands (csp:test, csp:stats, csp:prune, security:generate-csp). Optional Livewire dashboard is opt-in, so no forced frontend dependency. Extension points come through artisanpack-ui/hooks filters/actions — useful, but they are an escape hatch that can undo the package's guarantees, so they go behind code review. Two known release-quality data points to design around: pin the exact version (a bad export-ignore once shipped a tarball missing a registered command), and add our own tests around anything we rely on (a return-type bug survived in sanitizeFloat until 2.1.0). Proposed first milestone: security.headers + CSP in report-only with the violation endpoint wired to our alerting, plus the audit commands in CI; measure violations for two sprints before flipping to enforce.