How do I install and configure artisanpack-ui/security in a Laravel application?

Install it with Composer using composer require artisanpack-ui/security, then publish the package configuration and the CSP reports migration. Register the middleware aliases you need, such as csp and security.headers, and use the facade or global helpers in your application code. Confirm the correct config publish tag in the docs because the README and configuration docs may differ.

Which Laravel and PHP versions does artisanpack-ui/security support?

The package is positioned for Laravel 10 through 13 applications on PHP 8.2 and newer, but you should verify the exact Composer require constraints before adoption. Check the package composer.json and CI matrix for the definitive supported versions. If you are on an older Laravel or PHP release, test in staging first because middleware and helper behavior can vary.

What is included in artisanpack-ui/security 2.0?

Version 2.0 is core-only and includes input sanitization helpers, context-specific output escaping, KSES HTML filtering, NoHtml and SecureUrl validation rules, security middleware, CSP nonce and reporting support, and security audit Artisan commands. Authentication, 2FA, RBAC, secure uploads, analytics, and compliance are deliberately split into sibling packages. This makes it a tactical Laravel security baseline rather than a full application security platform.

How does CSP nonce generation work in this Laravel package?

The package provides a CSP nonce generator, policy builder, presets, a violation reporting endpoint, and Artisan commands such as csp:test and csp:stats. You add the generated nonce to allowed inline scripts and styles and serve the matching Content-Security-Policy header through the csp middleware. Start with reporting or report-only mode and confirm how nonces are cached, because a cache outage can affect nonce consistency.

Are the security:audit and security:scan commands safe to run in production?

Treat them as CI or staging tools first and confirm behavior against a production-like copy before running them on live systems. The package includes audit, scan, baseline, benchmark, config-check, header-test, and dependency-scan commands, but the documentation does not establish that every command is production-safe. Benchmark and scan commands in particular should be reviewed for load and side effects.

What are the default CSP and KSES policies and how strict are they?

The published configuration defines the CSP presets and the KSES allowed-tag policy, so inspect those files after publishing rather than assuming defaults. KSES filtering is WordPress-style and should be tuned to the rich-text elements your application actually needs. CSP defaults can break inline scripts, styles, fonts, or third-party integrations, so validate them with reporting before enforcement.

How do I avoid breaking data with sanitization and output escaping?

Do not apply blanket input sanitization everywhere; it can corrupt legitimate content, passwords, or structured data. Use validation rules and targeted sanitizers on input, then escape at output with the helper that matches the rendering context, such as escHtml, escAttr, escUrl, escJs, or escCss. Treat password sanitization cautiously because mutating passwords can reduce entropy or reject valid credentials.

Is api.security middleware compatible with my existing Sanctum API authentication?

The package depends on laravel/sanctum and provides api.security and api.rate_limit middleware, but its defaults may impose Sanctum-specific assumptions. Review the middleware source and configuration against your existing guards, token handling, and rate-limit strategy before enabling it globally. Test on a staging API to catch conflicts with custom authentication or throttling.

What alternatives should I consider before choosing artisanpack-ui/security?

Laravel's built-in validation, Blade escaping, and middleware can cover parts of this, while dedicated tools such as HTMLPurifier, Laminas Escaper, or an established CSP package may fit teams standardized elsewhere. This package is most defensible when you want Laravel-native helpers, KSES filtering, CSP reporting, and audit commands in one baseline. Avoid running duplicate CSP or HTML-sanitization stacks that create competing configuration surfaces.

How should I test the package and assess its maintenance before production use?

Run the package test suite and use csp:test, security:test-headers, security:check-config, and staging scans before rollout. Check the repository for a CI matrix, static analysis, security disclosure process, and actual release history because the package has zero stars and zero dependents and the listed release date may be unreliable metadata. Treat it as community-supported MIT software without an SLA unless the maintainer documents otherwise.

Security Laravel Package

ArtisanPack UI Security is the core Laravel security toolkit for the ArtisanPack UI ecosystem, focused on the fundamentals every app needs: input sanitization, output escaping, KSES filtering, security headers, XSS protection, rate limiting, and Content Security Policy. In 2.0 it stays deliberately core-only, with authentication, RBAC, uploads, analytics, and compliance moved to dedicated sibling packages.

It ships helpers like sanitizeEmail, sanitizeUrl, and escHtml, plus validation rules (NoHtml, SecureUrl), middleware (csp, security.headers, xss.protection), a CSP policy builder with presets and violation reporting, and Artisan audit/scan/benchmark commands for hardening and testing.

Sanitization & escaping — sanitize inputs and escape HTML, attributes, URLs, JS, and CSS
KSES filtering — WordPress-style allowed-tag filtering via kses()
Validation rules — NoHtml and SecureUrl for Laravel validators
Middleware — CSP, security headers, XSS protection, and API rate limiting
Security auditing — OWASP scanner, config checks, benchmarks, and CSP reporting