Laravel and PHP security checklist with a score

# Laravel and PHP security checklist

Score: 0% (High risk). 0 of 31 items in place.

## PHP and dependencies

- [ ] PHP is a version that still receives security fixes (check php.net/supported-versions.php)
- [ ] Laravel (or your framework) is on a release that still gets security fixes
- [ ] composer audit runs in CI and a known advisory fails the build or is reviewed
- [ ] Deploys use composer install from a committed composer.lock, never composer update on the server
- [ ] Packages marked abandoned are replaced
- [ ] Someone is alerted to new advisories for your dependencies (Dependabot, Renovate or Packagist notices)

## Configuration and secrets

- [ ] APP_DEBUG is false and APP_ENV is production on the live site
- [ ] The web server document root is the public folder, and nothing else in the project is reachable by URL
- [ ] APP_KEY is set, unique to each environment and has never been committed or shared
- [ ] The .env file is not in version control, and secrets come from the host or a secrets manager where possible
- [ ] The database user has only the rights the app needs, and the database is not open to the internet
- [ ] display_errors is off and expose_php is off in php.ini
- [ ] allow_url_include is off, and exec, system, passthru and proc_open are disabled if the app does not use them

## Application code

- [ ] Every route that reads or changes a record checks that the signed-in user owns it (policies or gates)
- [ ] Queries use Eloquent or bound parameters, and no user input is concatenated into raw SQL (whereRaw, DB::raw, selectRaw)
- [ ] Models define $fillable (or $guarded), and requests are never passed whole into create or update
- [ ] Blade output uses {{ }}, and {!! !!} appears only for content you have sanitised
- [ ] Uploads are validated by type and size, renamed and kept where PHP cannot run them
- [ ] All input goes through form requests or validators
- [ ] CSRF protection is on for all browser routes and exceptions are kept minimal
- [ ] unserialize() is never called on data a user can influence
- [ ] Login, password reset and API routes are rate limited
- [ ] Passwords are hashed with Hash::make, and admin accounts use two-factor authentication

## Server and tooling

- [ ] Telescope, Debugbar, Horizon, phpMyAdmin and similar tools are removed from production or locked behind strong authentication
- [ ] The web user can write only to storage and bootstrap/cache, not to the application code
- [ ] PHP-FPM runs as an unprivileged user, with a separate pool for each site on a shared server
- [ ] The whole site uses https, with HSTS and the usual security headers
- [ ] The web server passes only index.php to PHP, not every .php file

## Backups and review

- [ ] Database and uploaded files are backed up away from the server, and a restore has been tested
- [ ] Errors and sign-in events are logged somewhere you read, and logs hold no passwords or tokens
- [ ] A person has tested the application by hand in the last 12 months

## Fix first

1. PHP is a version that still receives security fixes (check php.net/supported-versions.php). Once a branch reaches end of life, new flaws are never patched and public exploits stay usable.
2. Laravel (or your framework) is on a release that still gets security fixes. Older major versions stop getting fixes, and attackers read the fix notes of newer versions to attack the old ones.
3. composer audit runs in CI and a known advisory fails the build or is reviewed. It checks every package in composer.lock against published advisories before the code ships.
4. APP_DEBUG is false and APP_ENV is production on the live site. Debug pages show stack traces, file paths and configuration values, and have been used to run code on exposed sites.
5. The web server document root is the public folder, and nothing else in the project is reachable by URL. Otherwise .env, composer.json, storage and source files can be downloaded.
6. APP_KEY is set, unique to each environment and has never been committed or shared. It encrypts cookies and sessions. A leaked key lets an attacker forge them, and on some versions run code.
7. Every route that reads or changes a record checks that the signed-in user owns it (policies or gates). Broken access control, where changing an id in the URL shows another customer's data, is the most common serious bug.
8. Queries use Eloquent or bound parameters, and no user input is concatenated into raw SQL (whereRaw, DB::raw, selectRaw). String-built queries are the classic route to SQL injection and a database dump.