- How do I install Laravel AccessProof?
- Install it as a development dependency with composer require --dev mykholy/laravel-accessproof:^1.2. You need PHP 8.3+ and Laravel 12/13, and you should run it against an isolated test database with synthetic fixtures. It is intended for test suites, not production runtime use.
- Which PHP and Laravel versions does laravel-accessproof support?
- Laravel AccessProof v1.2.1 supports PHP 8.3 and 8.4 plus Laravel 12 and 13. The release notes report verification on SQLite, MySQL 8, PostgreSQL 16, and an independent Laravel 13 application. Pin to ^1.2 and check the repository for updates before standardizing across teams.
- Is laravel-accessproof a production dependency?
- No. It is designed as a Composer --dev test-time authorization regression harness, not a production runtime dependency. Keep it out of production images and runtime service graphs; it belongs in local and CI test environments.
- Does Laravel AccessProof replace my existing policies and gates?
- No, it complements Laravel's gates, policies, middleware, and tenancy architecture rather than replacing them. It does not install authorization policies or take over runtime enforcement. Use it to verify that your existing access rules behave correctly under real HTTP tests.
- Does it automatically discover routes, policies, or authorization bugs?
- No. The package does not crawl routes, install policies, or automatically discover authorization gaps. Coverage depends on the scenarios your team writes. That makes scenario design and fixture setup the main adoption effort.
- What authorization regressions can Laravel AccessProof catch?
- It is aimed at authorization regressions such as IDOR/BOLA and cross-tenant data leaks. Typical scenarios include tenant selection, same-tenant object and role access, and cross-tenant related-record references. It uses real HTTP tests plus database state assertions to check what actually happened.
- Which databases can I use with Laravel AccessProof tests?
- The release notes list SQLite, MySQL 8, and PostgreSQL 16 as verified databases. Use isolated test databases and synthetic fixtures so row-state assertions are deterministic. A common approach is to run locally on SQLite and then validate in CI against your production-like database.
- Do passing AccessProof tests prove my Laravel app is secure?
- No. Passing tests are evidence for the scenarios you wrote, not a security certification or proof of authorization completeness. Coverage is bounded by your scenario design, and teams should avoid treating green tests as comprehensive authorization coverage. The reported field use was scoped regression testing on a private host.
- How do I pilot and maintain Laravel AccessProof in CI?
- Start with a pilot in one Laravel application's test suite: add the dev dependency, create disposable fixtures, and encode a small set of high-value tenant and cross-tenant scenarios. Run locally on SQLite, then add your CI database matrix. Pin to ^1.2 and review release notes for Laravel/PHP compatibility updates before broad rollout.
- What alternatives exist for Laravel authorization regression testing?
- Laravel's native gate and policy tests plus feature/integration tests with PHPUnit or Pest remain the baseline. Static analysis, code review, and dedicated security testing also complement regression tests. Laravel AccessProof is best viewed as a focused test-time harness alongside those practices, not a replacement.