Laravel Quarterly Security Review Checklist

Check for known vulnerabilities in your Composer dependencies. Update or replace packages with active security advisories. Review the changelog for any security-related changes in updated packages.

Apply the latest patch version within your major release (e.g., 11.x.y). Patch releases contain security fixes and bug fixes without breaking changes. Review the Laravel security changelog for details.

Ensure you are running a PHP version that still receives security updates. PHP versions receive active support for 2 years and security fixes for 1 additional year. Running an unsupported PHP version means no security patches.

Run npm audit and update frontend dependencies. JavaScript supply chain attacks are increasingly common. Review any new dependencies added since the last review for trustworthiness.

Verify that all SSL certificates have at least 30 days remaining before expiration. If using Let's Encrypt with auto-renewal, confirm the renewal process is working by checking the certificate dates.

Audit admin accounts for former employees, contractors, or test accounts that should be deactivated. Verify that every admin account belongs to a current team member who needs that access level.

Rotate long-lived API keys for third-party services (payment processors, email providers, cloud services). Update the corresponding values in your .env file and deployment secrets.

If your application uses OAuth for user authentication or API integrations, review the scopes requested and ensure they are still the minimum necessary. Revoke permissions that are no longer needed.

Review the MySQL or PostgreSQL user your application connects with. It should have only the permissions needed (SELECT, INSERT, UPDATE, DELETE on application tables). It should not have DROP, CREATE, or GRANT permissions.

Check that every account with administrative access has two-factor authentication enabled. Consider making 2FA mandatory for admin roles if it is not already required.

Configuration drift happens. Someone may have enabled debug mode for troubleshooting and forgotten to disable it. Check both the .env value and the actual response behavior by triggering a 404 or 500 error.

Check that Content-Security-Policy, Strict-Transport-Security, X-Frame-Options, X-Content-Type-Options, and Referrer-Policy headers are all present and correctly configured. Use a tool like securityheaders.com.

Review all DNS records for your domain. Remove CNAME records pointing to decommissioned services to prevent subdomain takeover. Verify SPF, DKIM, and DMARC records are still correct.

Look for repeated failed login attempts, unusual API usage patterns, 404s on sensitive paths (.env, wp-admin, telescope), and any authentication anomalies in your logs from the past quarter.

Verify that your database backups can actually be restored. A backup you cannot restore is not a backup. Test the full process at least quarterly, including restoring to a staging environment.