Nova Aegis Csp Laravel Package

Product Decisions This Supports

• Security baseline as a build-vs-buy call. A focused CSP package answers the recurring question "do we hand-roll Content-Security-Policy middleware, or take a dependency?" The scope is narrow and legible: middleware attaches a policy header, a service (CspService::header()) resolves the header value for a given scope, and an artisan command (TurnOffCsp) lets a team disable enforcement without ripping out code.
• Roadmap sequencing for hardening work. CSP is usually a compliance or audit follow-on to broader security work. This package makes CSP a one-sprint line item rather than a bespoke project, which matters when sequencing against SOC 2 prep, pen-test remediation, or a customer security questionnaire deadline.
• Environment-scoped rollout policy. The scope concept implies policies can differ by context (e.g. stricter in production, relaxed to report-only or off in local/staging). That is a product decision, not just a technical one: it determines whether violations break real users or only generate reports. Use it to define a staged rollout — report-only → enforced — before committing to enforcement dates.
• Incident-response posture. A single command to turn CSP off is an operational escape hatch. Decide in advance who is authorized to use it, and treat each use as a signal that the policy is misconfigured rather than that the package is failing.
• Adoption scope across the portfolio. If your organization runs multiple Laravel services, this is a candidate for a shared internal standard rather than per-team discretion — consistent security headers reduce audit surface and questionnaire churn.
• Evidence for security reviews. A named, versioned dependency is easier to cite in a security review than "we wrote some middleware." It gives reviewers a concrete artifact and a changelog to inspect.

When to Consider This Package

Adopt when:

• You ship a Laravel application that renders HTML in a browser and you need CSP headers without a dedicated frontend-security workstream.
• You want per-environment policy control (report-only in staging, enforced in production) and prefer configuration over custom middleware.
• Your team already follows Laravel-ecosystem conventions and values a small, auditable dependency over an in-house implementation.
• You need an operational kill switch so on-call can disable enforcement during an incident without a deploy.
• Security headers are a checklist item on an audit, questionnaire, or customer contract.

Look elsewhere or defer when:

• You are not on Laravel, or your app is a pure API/JSON service where CSP headers have no consumer.
• You need a full security-headers suite (HSTS, X-Frame-Options, Referrer-Policy, Permissions-Policy) and would rather consolidate on one larger package than compose several narrow ones.
• Nonce-based or hash-based CSP with per-request script injection is a hard requirement — validate that the scope model covers dynamic nonce generation before committing, since the release notes describe scope resolution, not nonce plumbing.
• You have an existing reverse-proxy or CDN layer that already sets headers; two sources of truth for CSP is a debugging hazard.
• Your team cannot absorb another dependency for a capability you can cover in roughly a hundred lines of middleware.

Watch item: v1.2.0 is explicitly an internal refactor with no application-facing change. That is a healthy signal — the maintainer is cleaning architecture without churning the public surface — but it also means this release adds no new product capability. Do not treat it as progress against any roadmap commitment.

How to Pitch It (Stakeholders)

For executives: This is a small, low-risk dependency that lets us ship a standard browser security control (Content Security Policy) in days instead of a bespoke build. It is configurable per environment, so we can turn it on in report-only mode first and prove it does not break the product before enforcing. It includes an operational off-switch for incidents. Cost is one dependency and a configuration file; the alternative is custom middleware we would own and maintain indefinitely.

For engineering: The package gives us CSP middleware, a CspService that resolves the header for a given scope, and a TurnOffCsp command. The scope model is the interesting part — it decides which policy applies where, so it is where we should spend review time. v1.2.0 changes internal signatures only: CspService::header() now receives the resolved scope rather than the request, and the disable command delegates to TurnOffCsp. No action required from consuming applications. Recommended next step is a spike in staging using report-only mode to collect violation telemetry, then a go/no-go on enforcement based on that data.

Caveat to state plainly: we are approving this on a single internal-refactor release with limited public documentation reviewed. Before enforcement, someone must confirm nonce handling and confirm no header conflicts with our CDN or proxy layer.