Laravel is one of the safer ways to build a PHP application. Out of the box it protects forms against cross-site request forgery, escapes output in templates, uses parameter binding for database queries and hashes passwords properly. That is a big head start.
But defaults are not the same as security. Most real-world incidents in Laravel applications come from configuration slips, missing permission checks, risky file uploads and outdated packages - not from the framework itself. If your business is about to launch a portal, ERP, SaaS product or customer app built on Laravel, this checklist is what we recommend reviewing first.
You do not need to understand every line technically. Use it to ask your development team the right questions.
Part 1: Configuration and secrets
1. Debug mode is off in production
APP_DEBUG must be false on the live server. With debug on, error pages can expose file paths, environment values and database details. A well-known 2021 vulnerability in an older version of the Ignition error-page package allowed remote code execution specifically on sites running with debug mode enabled.
2. The .env file is not publicly reachable
The web server's document root should point to Laravel's public folder only. The .env file, which holds database passwords and API keys, must never be downloadable from the browser. Test it by trying to open it in a browser yourself.
3. APP_KEY is unique and secret
Laravel uses the application key to encrypt data and sign cookies. It should be generated for each environment, kept out of the code repository, and never shared in chats or emails.
4. Secrets are not committed to Git
Payment gateway keys, SMS and WhatsApp API tokens, and mail passwords belong in environment variables, not in code. Check the repository history too - deleted secrets remain in old commits and should be rotated.
5. Development tools are disabled or protected
Debug toolbars and Laravel Telescope are excellent during development but should be disabled in production or locked behind admin-only access.
Part 2: Authentication and access
6. Strong login protection
Rate-limit login attempts (Laravel's throttle middleware and RateLimiter make this straightforward), enforce sensible password rules, and offer two-factor authentication for admin and finance users. Laravel's Fortify package supports two-factor authentication.
7. Authorisation on every record
This is one of the most common gaps. Logging in proves who someone is; it does not prove they should see a particular invoice. Every request that loads a record by ID must check ownership or permission, using Laravel policies and gates. Test it: log in as one customer, change the ID in the URL, and see if another customer's data appears.
8. Roles and permissions are clearly defined
Map exactly what each role - admin, manager, staff, dealer, customer - can view, create, edit, delete and export. Export permissions matter: a single "download all customers" button can leak an entire database.
9. API tokens are scoped and revocable
If a mobile app or third-party system uses your API, use Laravel Sanctum or Passport, give tokens only the abilities they need, and make sure they can be revoked when a device is lost or an employee leaves.
10. Sessions are secure
Serve the whole application over HTTPS, mark session cookies as secure and HTTP-only, and set sensible session lifetimes, especially for admin users.
Part 3: Input, output and data
11. All input is validated
Use Laravel's validation, ideally through Form Request classes, for every form and API endpoint - including hidden fields and values that "users cannot change". Attackers can change anything a browser sends.
12. Mass assignment is controlled
Laravel models should define which fields can be filled from user input (using the fillable or guarded settings). Otherwise a user might set fields such as "role" or "is_admin" by adding them to a request.
13. Raw queries and unescaped output are reviewed
Eloquent and the query builder protect against SQL injection, but raw query fragments that include user input do not. Similarly, Blade's double-brace syntax escapes output, while the unescaped syntax does not. Ask for every raw query and every unescaped output to be reviewed.
14. Sensitive data is encrypted or minimised
PAN, Aadhaar-related details, bank information and medical records deserve special care. Store only what you need, encrypt sensitive fields (Laravel supports encrypted model attributes), and restrict who can view them. Under the Digital Personal Data Protection Act, 2023, collecting less is often the simplest protection.
Part 4: Files and uploads
15. Uploads are validated and stored safely
Restrict file types and sizes with validation rules, rename uploaded files, and store private documents outside the public folder. Serve them through a controller that checks permission, or with temporary signed URLs.
16. No executable uploads
The upload folder should never allow PHP execution. A disguised PHP file uploaded as an "image" is a classic way attackers take over servers.
Part 5: Dependencies, server and monitoring
17. Laravel, PHP and packages are on supported versions
Laravel versions receive security fixes for two years; PHP versions have their own support windows. Running composer audit checks installed packages against known vulnerability databases. Make this a routine, not a one-time check.
18. Security headers are set
Add HTTPS with HSTS, plus headers such as X-Frame-Options or a frame-ancestors rule, X-Content-Type-Options and, where practical, a Content Security Policy.
19. Backups are automatic, offsite and tested
Daily database and file backups stored away from the main server, with a restore actually tested. A backup you have never restored is a hope, not a plan.
20. Logs and alerts exist
Log logins, failed logins, permission changes and data exports. Set up alerts for repeated failures and server errors. Make sure logs do not contain passwords or full card or identity numbers. CERT-In's 2022 directions also require many organisations in India to report certain cyber incidents within six hours, which is only possible if you can detect them.
The checklist at a glance
| Area | Key checks | Owner |
|---|---|---|
| Configuration | Debug off, .env protected, keys secret, dev tools disabled | Developer / DevOps |
| Access | Rate limits, 2FA for admins, policies on every record, scoped API tokens | Developer |
| Data | Validation, mass assignment rules, raw query review, encryption | Developer |
| Files | Type and size limits, private storage, no execution in upload folders | Developer / DevOps |
| Operations | Updates, composer audit, security headers, tested backups, logging | DevOps / maintenance team |
| Business | Role matrix approved, data minimised, incident contact defined | Business owner |
What the business owner should own
Security is not only a developer task. As the owner, you should:
- Approve the role and permission matrix - who can see and export what.
- Decide what personal data you truly need to collect.
- Make sure you hold the credentials - server, domain, code repository and key third-party accounts.
- Remove access promptly when staff or vendors leave.
- Agree on who to call if something goes wrong, and how fast they respond.
- Ask for a short security summary at handover: what was checked, which settings are in place and what remains a known risk.
Five quick checks you can do yourself
- Open your domain followed by /.env in a browser - you should see an error, not a file full of settings.
- Visit a page that does not exist or trigger a form error - you should see a plain error page, not a detailed technical stack trace.
- Try logging in with a wrong password several times - you should be slowed down or temporarily blocked.
- Log in as one test customer and change a record ID in the address bar - you should never see someone else's data.
- Try uploading a file type the form should not accept - it should be rejected with a clear message.
If any of these fail, raise it with your developer before launch.
Key takeaways
- Laravel's defaults are strong, but configuration and permission mistakes are where most problems start.
- Debug mode off, .env protected, authorisation on every record and safe uploads are non-negotiable.
- Keep Laravel, PHP and packages updated and check dependencies regularly.
- Backups only count if a restore has been tested.
- Owners should approve roles, minimise personal data and hold all key credentials.
Get your Laravel application reviewed
MetaFox Technologies has 6+ years of experience building and maintaining business applications, with a 25+ person in-house team in Jaipur. If you are preparing to launch - or are worried about an existing app - book a free consultation. We will discuss a code and configuration review and send a written scope and quote. Learn more about our Laravel development services, cyber security services and website maintenance plans.
