In nearly every audit we run, we find at least one issue serious enough to expose customer data, and the team had no idea it was there. Not because they were careless, but because the app was built fast, under pressure, by people focused on shipping features rather than hunting for the gap between "it works" and "it's safe." That gap is exactly where a security audit lives.
This post walks through what a real audit looks at, the kinds of vulnerabilities we find most often in Laravel SaaS apps, and what those findings actually cost you if they go unfixed. The findings are anonymised, but they're real, drawn from audits of production applications with paying customers.
What a security audit is (and isn't)
A web application security audit is a structured, deliberate examination of your codebase, configuration, and infrastructure to find ways an attacker could read data they shouldn't, act as someone they're not, or break something that should hold.
It is not the same as a few things people often confuse it with:
- It isn't a vulnerability scanner. Automated scanners are useful for catching known issues at scale, but they don't understand your business logic. A scanner won't notice that your /invoices/{id} endpoint lets one customer read another customer's invoice, because technically the code "works." Most real-world SaaS breaches come from logic flaws a scanner can't see.
- It isn't a code-quality review. We're not telling you your variable names are messy. We're asking: if someone wanted to get in, where would they get in?
- It isn't a one-time guarantee. Security is a moving target. An audit tells you where you stand today and hardens the most dangerous gaps. It doesn't freeze your app in a "secure" state forever.
A good audit combines automated tooling (to cover the breadth of known issues quickly) with manual review by someone who has actually broken into applications before. The manual part is where the value is. Tools find the obvious; people find the expensive.
The 7 things we check first in a Laravel SaaS app
Laravel is a genuinely secure framework when used as intended. It gives you CSRF protection, hashed passwords, parameterised queries, and sane defaults out of the box. The problem is almost never Laravel itself. It's the places where a team worked around those defaults to ship a feature faster. Here's where we look first.
1.** Exposed secrets and configuration**: The single most common critical finding. We check whether .env is reachable from the web, whether APP_DEBUG is set to true in production, and whether API keys, database credentials, or third-party tokens have leaked into version control or error pages. A production app running in debug mode will happily print a full stack trace, including database credentials and file paths, to anyone who triggers an error. 2. Authentication and session handling: We review how passwords are hashed, how sessions are configured, how "remember me" tokens are handled, and whether multi-factor authentication is available for accounts that need it. We check for session fixation, insecure cookie flags, and tokens that never expire. 3. ** Tenant isolation (the SaaS-specific one)**: This is the check that matters most for a SaaS security audit and the one most likely to surface a serious bug. In a multi-tenant app, every query that touches customer data must be scoped to the current tenant. We test whether changing an ID in a URL, an API call, or a form lets one customer reach another's data. This single class of bug (broken object-level authorization) is responsible for a large share of real SaaS data leaks. 4. Mass assignment: Laravel's $fillable and $guarded exist to stop a user from setting fields they shouldn't. We check whether any model lets a malicious request set something dangerous (like flipping their own is_admin flag or changing the account_id that owns a record) simply by adding an extra field to a form submission. 5. Input validation and injection: We look for raw database queries built from user input, unsafe use of DB::raw(), unescaped output that opens the door to cross-site scripting, and file uploads that don't validate type or location. Eloquent protects you from SQL injection by default; the risk lives wherever someone bypassed it. 6. Rate limiting and abuse protection: We check whether login, password-reset, and API endpoints are throttled. An app with no rate limiting on its login route is an open invitation for credential-stuffing attacks: automated attempts to log in using passwords leaked from other breaches. We've seen apps with no throttling at all on authentication. 7. Dependencies and known vulnerabilities: We audit your composer.lock and JavaScript dependencies against databases of known vulnerabilities (CVEs). A single outdated package with a published exploit can undo every other good decision you've made. This is fast to check and fast to fix, yet it's overlooked constantly.
Real findings from real audits (anonymised) To make this concrete, here are findings from actual audits. Details are changed to protect the companies, but the issues are exactly as we found them. The debug switch that leaked the database. A B2B SaaS app with several hundred paying customers had APP_DEBUG=true left on in production. Any user who triggered an unhandled error saw a full Laravel stack trace, including the database host, username, and the structure of internal queries. The fix took five minutes. Had an attacker found it first, it would have been the starting map for a full breach. The invoice you weren't supposed to see. A billing endpoint looked like /api/invoices/{id}. The controller fetched the invoice by ID and returned it, but never checked that the invoice belonged to the logged-in customer's account. By simply incrementing the ID, any customer could pull up the invoices of every other customer on the platform: names, amounts, billing addresses. The code "worked" perfectly in every test. It was a textbook broken-authorization flaw, and a scanner would never have caught it. The self-promotion bug. A user-profile update form accepted a role field via mass assignment. The front end never showed that field, so nobody thought about it. But a user could add role=admin to the request payload and grant themselves administrator access to the entire tenant.
The login with no lock. An app had zero rate limiting on its login route. We demonstrated thousands of automated login attempts in minutes with no throttling, lockout, or alerting, leaving every account exposed to credential stuffing using passwords from public breach dumps.
None of these companies were negligent. They were moving fast and building product. These are the Laravel vulnerabilities that hide in the seams of an app built under deadline pressure, invisible until someone goes looking.
What it costs you to not fix these
It's tempting to file security under "later." Here's the honest math on why that's the most expensive line item you're not tracking.
- Direct breach cost. Incident response, forensic investigation, legal counsel, and remediation routinely run into tens of thousands even for a small company, before you count any regulatory fines.
- Customer churn. For a SaaS business, trust is the product. A breach notification email is one of the fastest ways to trigger cancellations, and B2B customers with their own compliance obligations may be contractually forced to leave.
- Stalled deals. Increasingly, enterprise and mid-market buyers send a security questionnaire before they'll sign. An app that can't answer it (or fails a prospect's own security review) loses the deal silently. You often never even learn why.
- Regulatory exposure. Depending on where your customers are and what data you hold, a leak of personal data can trigger obligations under GDPR, UK GDPR, or US state laws, with penalties attached.
- Founder time and focus. The hidden cost. A breach mid-growth pulls your whole team off the roadmap for weeks. Nothing kills momentum like a security incident.
Against all of that, a proactive audit is one of the cheapest pieces of insurance a SaaS company can buy. The findings above each took minutes to hours to fix, once someone knew to look.
How an audit actually works, step by step
If you've never commissioned one, here's exactly what the process looks like with us, so there are no
- Scoping. We agree on what's in scope (the application, the API, the infrastructure, or all three) and what "done" looks like. We get read access to the codebase and a walkthrough of how the app is meant to work.
- Automated baseline. We run tooling across dependencies, configuration, and common vulnerability classes to catch the known-issue breadth quickly and free up time for the manual work.
- Manual review. The core of the audit. We read the code the way an attacker would, focusing on authentication, authorization, tenant isolation, and business logic: the things tools can't reason about.
- Verification. For each suspected issue, we confirm it's actually exploitable rather than theoretical, so you're not chasing false alarms. Every finding is something real.
- Reporting. You get a clear report: each finding rated by severity, explained in plain language, with a concrete fix and the reasoning behind it. Prioritised so you know what to do first.
- Remediation support. We don't hand you a PDF and disappear. We help your team implement the fixes, or implement them ourselves.
- Retest. Once fixes are in, we verify they actually closed the gap, because a half-applied fix can be worse than none.
The whole thing is built to leave you genuinely more secure and able to prove it to customers and prospects, not just holding a document.
Find out where your Laravel app actually stands Most of the issues in this post were invisible to the teams that built the apps, right up until we showed them. If you're running a Laravel SaaS app with real customers and you've never had it independently reviewed, the responsible assumption is that something in here applies to you too.
We're a development agency with hands-on security credentials (CEH, CompTIA Security+) and audit experience across production SaaS applications. A Laravel security audit with us is practical, plain-spoken, and aimed at making you safer, not at selling you fear.
Book a free 20-minute walkthrough. We'll talk through your stack, flag the highest-risk areas to check first, and tell you honestly whether a full audit is even worth it for you yet. No pressure, no jargon.
