Laravel Post-Breach Response Checklist

If the APP_KEY was compromised (through .env exposure), generate a new one with php artisan key:generate. This invalidates all encrypted data, sessions, and cookies. All users will be logged out.

Change database passwords, third-party API keys, mail credentials, and any other secrets in your .env file. Start with payment processor and banking API keys — these have the highest immediate risk.

Set APP_DEBUG=false immediately. Every error page in debug mode continues to leak credentials and application internals while the incident is ongoing.

If using database sessions, truncate the sessions table. If using Redis, flush the session store. This forces all users to re-authenticate with clean sessions.

Review access logs, application logs, and error logs to determine how the attacker gained access and when the breach started. Check for .env access, debug page hits, Telescope access, and unusual API requests.

Based on the attack vector, determine what data the attacker could have accessed. If .env was exposed, assume all credentials were compromised. If debug mode was on, check what data appeared in error pages.

Review recent file changes, new user accounts (especially admin), modified routes, and any cron jobs or scheduled tasks that were not present before. Check for webshells in the storage or public directories.

Check for new admin users, modified permissions, changed email addresses on existing accounts, and any data that has been altered. Compare against your most recent backup if possible.

Address the specific vulnerability that was exploited. If .env was exposed, configure your web server to block dotfile access. If debug mode was on, add deployment checks. Fix the root cause, not just the symptom.

If user credentials may have been compromised, force a password reset for all affected accounts. Notify users with clear instructions and explain what happened without unnecessary alarm.

Run composer update and check for any security patches in Laravel, PHP, and your server software. The breach may have exploited a known vulnerability that has already been patched.

Add the security measures that would have prevented or detected the breach earlier: security headers, access restrictions on admin tools, external monitoring, rate limiting, and 2FA for admin accounts.

Most jurisdictions require breach notification within a specific timeframe (72 hours under GDPR, varies by state in the US). Be transparent about what happened, what data was affected, and what steps you are taking.

Create a detailed incident report with the timeline, attack vector, data impact, containment steps, and remediation actions. This document is essential for regulatory compliance and internal learning.

Deploy external security monitoring (like StackShield) to continuously check for the types of exposures that led to the breach. Automated monitoring catches configuration drift before it becomes a vulnerability.

Hold a blameless post-mortem to discuss what happened, what worked well in the response, and what processes need to change. Document action items and assign owners for each improvement.