Laravel Pre-Launch Security Checklist

Essential security checks to complete before launching your Laravel application. Covers code review, configuration audit, infrastructure, and monitoring setup.

Progress

0 / 20 completed

Code & Dependency Review

Run composer audit to check for known vulnerabilities

The composer audit command checks your installed packages against the PHP Security Advisories database. Fix or update any packages with known CVEs before launching.

Review all uses of {!! !!} in Blade templates

The unescaped output syntax {!! !!} can introduce XSS vulnerabilities if used with user-supplied data. Search your entire codebase and ensure each usage is intentional and safe.

Check for raw database queries with unsanitized input

Search for DB::raw(), whereRaw(), selectRaw(), and DB::statement() calls. Verify that all user input is passed as bound parameters, not concatenated into SQL strings.

Review file upload handling for type and size validation

Ensure all file upload endpoints validate MIME types, file extensions, and file sizes. Store uploads outside the web root and serve them through a controller with proper access checks.

Remove all development-only routes and test endpoints

Search for routes that were added for testing or debugging. Remove any endpoints that return phpinfo(), dump debug data, or bypass authentication. Check both web.php and api.php.

Configuration Audit

Verify APP_DEBUG=false and APP_ENV=production

Double-check your production .env file. Debug mode is the most commonly exploited Laravel misconfiguration. A single error page in debug mode reveals your entire environment.

Confirm APP_KEY is unique and not from development

The production APP_KEY must be unique and never committed to version control. If your development key was ever exposed (committed to Git, shared in a chat), generate a new one.

Review config/session.php security settings

Verify secure is true, http_only is true, and same_site is set to lax or strict. Check that the session lifetime is appropriate for your application's sensitivity level.

Review config/cors.php for overly permissive settings

Ensure allowed_origins is set to specific domains, not the wildcard (*). Check that allowed_methods and allowed_headers are restricted to what your application actually needs.

Verify mail configuration uses production credentials

Ensure you are not using Mailtrap, log, or array mail drivers in production. Verify MAIL_FROM_ADDRESS is set to a real domain you control with proper SPF/DKIM records.

Infrastructure & DNS

Install and verify SSL certificate for all domains

Ensure your SSL certificate is valid, not expired, and covers all subdomains you use. Test with an SSL checker tool. Set up auto-renewal if using Let's Encrypt.

Configure DNS records for email authentication (SPF, DKIM, DMARC)

Set up SPF, DKIM, and DMARC records to prevent email spoofing from your domain. This protects your users from phishing attacks that impersonate your application.

Verify firewall rules block direct database access

Ports 3306 (MySQL), 5432 (PostgreSQL), 6379 (Redis), and 11211 (memcached) must not be accessible from the public internet. Test with a port scanner from an external network.

Set up automated backups with offsite storage

Configure daily database backups stored in a separate location from your application server. Test backup restoration to verify backups are complete and usable.

Remove any staging or development DNS records

Stale DNS records pointing to decommissioned services can be exploited for subdomain takeover attacks. Audit your DNS zone for records pointing to unused services.

Monitoring & Incident Response

Set up error monitoring (Sentry, Bugsnag, or Flare)

Production errors should be captured and alerted on, not displayed to users. Configure an error monitoring service to track exceptions, performance issues, and deployment regressions.

Configure uptime monitoring

Monitor your application's availability and response time. Get alerted immediately when your application goes down or response times exceed acceptable thresholds.

Set up external security monitoring with StackShield

Continuous external security monitoring catches configuration drift, expired SSL certificates, exposed debug tools, and missing security headers that internal monitoring misses.

Document an incident response plan

Define who gets notified, what steps to take, and how to communicate with users if a security incident occurs. Even a simple one-page plan is better than no plan at all.

Set up log aggregation and retention

Centralize your application and server logs in a searchable system. Define a retention period that meets your compliance requirements. Logs are essential for post-incident investigation.

Frequently Asked Questions

How long before launch should I start the security checklist?

Start at least one week before launch. Some items (like DNS configuration and SSL certificate propagation) take time to take effect. Running composer audit and code review early gives you time to fix issues without delaying the launch.

What if I find a vulnerability right before launch?

Assess the severity. Critical vulnerabilities (exposed .env, debug mode, SQL injection) must be fixed before launch. Medium-severity issues (missing security headers, suboptimal session config) should be fixed within the first week. Document everything for your security log.

Do I need a penetration test before launching?

A penetration test is recommended but not strictly required for every launch. At minimum, complete this checklist and set up continuous monitoring. For applications handling sensitive data (financial, healthcare, PII), schedule a penetration test within the first 90 days.