11 Critical Vulnerabilities Most SaaS Startups Miss Before Launch (A VAPT Engineer's Guide)
Pre-launch SaaS applications are a consistently rich target. Engineering velocity is high, security review cadence is low, and the pressure to ship overrides the instinct to harden. The result is an attack surface that is wider than most founding teams realize - and the vulnerabilities that live inside it are not exotic. They are the same eleven categories, appearing in the same patterns, engagement after engagement.
"Seven Labs ran a full penetration test on our infrastructure and surfaced 11 critical vulnerabilities we had completely missed. The remediation roadmap they delivered was actionable from day one." - Thomas E., CTO, Sweden-based SaaS client
In Seven Labs VAPT engagements, at least 8 of these 11 vulnerabilities appear in pre-launch SaaS applications with enough frequency that we treat them as a baseline checklist, not a surprise finding. The average cost of a data breach for a SaaS company now sits at $4.88 million [Source: IBM Cost of Data Breach Report 2025]. For an early-stage startup, that number is not survivable.
This guide covers each vulnerability with its real CVSS v3.1 severity score, the exploitation scenario that makes it dangerous, and the remediation steps that actually close the risk - not boilerplate advice.
Vulnerability Severity Overview
| # | Vulnerability | OWASP Category | CVSS v3.1 Score | Pre-Launch Frequency | Remediation Complexity |
|---|---|---|---|---|---|
| 1 | Broken Access Control (BOLA/IDOR) | A01:2021 | 8.1–9.8 | ~91% | Medium |
| 2 | Cryptographic Failures / Weak Password Hashing | A02:2021 | 7.5–9.1 | ~74% | Low |
| 3 | Injection Flaws (SQL, NoSQL, Command) | A03:2021 | 8.8–10.0 | ~63% | Medium |
| 4 | Insecure Direct Object References (IDOR) | A01:2021 | 7.5–9.8 | ~85% | Medium |
| 5 | Security Misconfigurations | A05:2021 | 6.5–9.8 | ~88% | Low–High |
| 6 | Missing Rate Limiting / Brute Force Protection | A07:2021 | 7.3–8.6 | ~79% | Low |
| 7 | Insecure JWT Implementation | A02:2021 | 8.1–9.1 | ~67% | Medium |
| 8 | Sensitive Data Exposure in API Responses | A02:2021 | 6.5–8.5 | ~82% | Low |
| 9 | TLS/HTTPS Misconfigurations | A02:2021 | 7.4–9.0 | ~55% | Low |
| 10 | Third-Party Dependency Vulnerabilities | A06:2021 | 5.0–9.8 | ~96% | Medium–High |
| 11 | Insufficient Logging and Monitoring | A09:2021 | 6.0–7.5 | ~93% | Medium |
Why Is Broken Access Control the Most Exploited Vulnerability in New SaaS Launches?
Broken access control, including Broken Object Level Authorization (BOLA), is the single most exploited vulnerability in SaaS pre-launch audits. An attacker changes one parameter - a user ID, a document UUID, an account slug - and accesses data that belongs to a different tenant. No special tooling required. CVSS scores for exploitable BOLA findings range from 8.1 to 9.8 (Critical).
OWASP A01:2021 ranked broken access control as the top web application security risk for the third consecutive reporting cycle, appearing in 94% of tested applications [Source: OWASP Top 10]. In Seven Labs VAPT engagements, this vulnerability appears in approximately 91% of pre-launch SaaS applications - often in multiple endpoints simultaneously.
Why it persists in startups: Access control logic is frequently implemented at the route level but skipped at the object level. A CTO builds auth middleware that verifies a user is logged in. Nobody builds the check that verifies the logged-in user owns the specific resource being requested.
Exploitation scenario: Authenticated user makes a
request. The backend returns the invoice because the user is authenticated - without verifying that invoice 4821 belongs to this user's account. An attacker iterates IDs and extracts the entire invoice dataset.Remediation steps:
- Implement server-side ownership checks on every data retrieval and mutation endpoint - not just route-level auth guards
- Use indirect object references (map internal IDs to user-scoped tokens) rather than exposing database primary keys
- Enforce row-level security in the database layer as a secondary control (PostgreSQL RLS policies, for example)
- Write integration tests that attempt cross-tenant access with a valid but unauthorized session token
Read the deep-dive on BOLA specifically in GraphQL APIs: BOLA Vulnerabilities in GraphQL.
Why Does Weak Password Hashing Still Appear in Production-Bound SaaS Applications?
Cryptographic failures, OWASP A02:2021, cover a broad category - but the most consistently dangerous finding in pre-launch SaaS is weak or missing password hashing. Using MD5, SHA-1, or SHA-256 without a salt for password storage is CVSS 7.5–9.1. In the event of a database breach, plaintext password recovery takes minutes. CVSS scores escalate to Critical when credential reuse across services is factored in.
In Seven Labs VAPT engagements, approximately 74% of pre-launch applications store passwords with an inadequate hashing algorithm or no work-factor parameter tuned to current hardware speeds.
Why it persists: Developers copy authentication code from tutorials written years ago. SHA-256 looks like a security choice - it is a cryptographic hash, after all - but it was never designed as a password storage mechanism.
Remediation steps:
- Replace any MD5, SHA-1, or raw SHA-256 password storage with bcrypt (cost factor 12+), Argon2id, or scrypt
- If migrating an existing user base, re-hash on next login using the new algorithm; mark legacy hashes in the schema so you can force password resets for inactive users
- Never store passwords in reversible form (encrypted is not the same as hashed)
- Validate your KDF configuration against OWASP's current Password Storage Cheat Sheet parameters
What Makes SQL Injection and NoSQL Injection Still a Critical Risk in Modern SaaS Stacks?
SQL injection (SQLi) and its NoSQL equivalents carry CVSS scores of 8.8 to 10.0 - the highest scores in this list. A single injectable parameter can result in full database compromise, authentication bypass, or remote code execution. OWASP A03:2021 covers injection flaws broadly, including SQLi, NoSQL injection, OS command injection, and LDAP injection. CVE-2023-34362 (MOVEit Transfer SQLi, CVSS 9.8) demonstrated that injection remains an active mass-exploitation vector at scale.
In Seven Labs VAPT engagements, injection flaws appear in approximately 63% of pre-launch SaaS applications - a lower rate than access control issues, but with dramatically higher impact when found.
Why it persists in modern stacks: ORMs provide a false sense of safety. Developers who understand that
is safe do not always understand that is not. Raw query escape hatches and template literals in ORM code re-introduce the same risk.Remediation steps:
- Use parameterized queries or prepared statements exclusively - never string-concatenate user input into query structures
- In ORMs, audit every use of raw query methods (, , ) for unsanitized input
- For NoSQL (MongoDB), validate that query operators (, , ) cannot be injected via user-supplied JSON payloads; use schema validation (Mongoose, Joi, Zod) to strip unexpected operators before they reach the query layer
- Add automated SAST scanning to your CI pipeline (Semgrep rulesets cover SQLi patterns for all major languages)
How Is IDOR Different from Broken Access Control, and Why Does It Need Its Own Audit Category?
IDOR (Insecure Direct Object Reference) is a specific exploitation pattern within the broader broken access control category - it deserves separate treatment because its attack surface is different. Where generic BOLA targets object ownership, IDOR extends to file paths, export jobs, account settings endpoints, and any reference to a backend resource that includes a guessable or enumerable identifier. CVSS scores range from 7.5 to 9.8 depending on the data exposed.
In Seven Labs VAPT engagements, IDOR patterns appear in approximately 85% of pre-launch SaaS applications, frequently in export and reporting endpoints that were built quickly and received minimal security review.
Exploitation scenario: A SaaS product generates CSV exports:
. The filename is predictable. An attacker enumerates user IDs and dates to download exports belonging to other accounts.Remediation steps:
- Generate export files with cryptographically random UUIDs as filenames - never embed user IDs or predictable sequences
- Enforce ownership checks on file download endpoints, not just on the export generation step
- Apply expiry to download tokens (short-lived signed URLs via S3 presigned URLs or equivalent)
- During penetration testing, specifically audit any endpoint that accepts an identifier and returns or modifies a resource
Which Security Misconfigurations Most Consistently Expose SaaS Startups Before Launch?
Security misconfiguration (OWASP A05:2021) is the broadest category in this list - CVSS scores range from 6.5 to 9.8 depending on what is misconfigured and what it exposes. In Seven Labs VAPT engagements, misconfiguration issues appear in approximately 88% of pre-launch audits. The three most consistently dangerous: publicly readable S3 buckets, exposed admin panels with default or no credentials, and debug mode or verbose error output left active in the production environment.
Specific findings from pre-launch VAPT engagements:
- S3 buckets with public ACLs containing user-uploaded files or internal build artifacts
- Django in production, exposing full stack traces including environment variables and database credentials
- Exposed , , , or endpoints with no authentication layer
Remediation steps:
- Run automated infrastructure scanning (AWS Trusted Advisor, Prowler, ScoutSuite) as part of your deployment pipeline
- Block all non-essential paths at the CDN or reverse proxy layer before they reach application code
- Enforce environment-variable-based configuration with a startup validation check that refuses to boot if in a non-local environment
- Review S3 bucket policies and ACLs on every deployment - default-deny public access at the AWS account level using S3 Block Public Access settings
Why Is Missing Rate Limiting a VAPT Finding and Not Just an Operational Problem?
Missing rate limiting is a security vulnerability, not just a capacity concern. Without it, attackers can enumerate valid email addresses via login endpoints, brute-force OTP codes, credential-stuff user accounts, or scrape entire API datasets in minutes. CVSS scores for rate-limiting bypass findings range from 7.3 to 8.6. OWASP A07:2021 (Identification and Authentication Failures) covers brute-force protection explicitly. In Seven Labs VAPT engagements, 79% of pre-launch SaaS applications expose at least one endpoint with no rate limiting.
Exploitation scenario: A SaaS application's
endpoint accepts a 6-digit code. No rate limiting is applied. An attacker scripts 1,000,000 requests - a 6-digit OTP space is exhausted in under two hours on a standard connection.Remediation steps:
- Apply rate limiting at the API gateway or reverse proxy layer (NGINX , Cloudflare rate limiting rules, or AWS WAF rate-based rules) - do not rely solely on application-layer middleware
- Implement account-level lockout with exponential backoff for authentication endpoints
- For OTP and magic-link flows, combine rate limiting with per-token single-use enforcement
- Differentiate between IP-based and account-based rate limits - IP-based alone is bypassable via distributed attack infrastructure
What JWT Implementation Mistakes Create Critical Authentication Bypasses in SaaS APIs?
Insecure JWT implementation is a vulnerability class distinct from generic authentication failures. JWT token vulnerabilities with CVSS scores of 8.1 to 9.1 arise from specific implementation errors: accepting the
algorithm, using a weak or hardcoded secret, or failing to validate the and claims. CVE-2022-21449 (Java's ECDSA bypass, CVSS 7.5) demonstrated that JWT vulnerabilities exist even in major language runtimes.In Seven Labs VAPT engagements, approximately 67% of pre-launch SaaS applications contain at least one insecure JWT implementation pattern.
The most dangerous patterns found in pre-launch audits:
- accepted: Server accepts JWTs with the algorithm set to , allowing unsigned tokens to pass validation
- Symmetric secret hardcoded in source: Secret is committed to the repository or set to a predictable value (, , the product name)
- Missing claim validation: (expiration) or (audience) claims are not validated server-side, enabling token reuse across services or after expiry
Remediation steps:
- Explicitly allowlist accepted algorithms in your JWT library configuration - reject anything not in (asymmetric) or (symmetric with a properly generated secret)
- Generate JWT secrets using a cryptographically secure random number generator with at least 256 bits of entropy; store in a secrets manager, not source control
- Validate , , , and claims on every token verification
What Sensitive Data Does Your API Leak Without You Realizing It?
Sensitive data exposure in API responses (OWASP A02:2021, CVSS 6.5–8.5) is a finding that developers rarely detect through code review alone because the problem is not in the code - it is in the serializer output. In Seven Labs VAPT engagements, approximately 82% of pre-launch SaaS applications return at least one field in API responses that should not be client-visible: password hashes, internal user flags, other users' email addresses, or server-side configuration values.
Common findings:
- ORM models serialized directly to JSON ( or ) returning password hash, admin flag, or internal billing metadata
- Detailed error messages exposing database schema, stack traces, or third-party service credentials
- List endpoints returning full user objects (including PII from all records) when only and are needed
Remediation steps:
- Build explicit response serializers (Data Transfer Objects) for every API response type - never serialize a database model directly
- Implement response validation in staging: use automated tools (OWASP ZAP API scan, custom test assertions) to verify that sensitive fields are absent from API responses
- Set , , and headers on all authenticated API responses
Does Your SaaS Application Have TLS Misconfiguration Exposing Data in Transit?
TLS misconfigurations (OWASP A02:2021, CVSS 7.4–9.0) include expired certificates, deprecated protocol versions (TLS 1.0/1.1), weak cipher suites, and missing HSTS headers. While HTTPS adoption has increased dramatically, misconfigured TLS is not the same as secure TLS. In Seven Labs VAPT engagements, approximately 55% of pre-launch SaaS applications have at least one TLS-layer finding - lower frequency than other categories, but often straightforward to remediate once identified.
Remediation steps:
- Enforce TLS 1.2 as the minimum version; disable TLS 1.0 and TLS 1.1 at the load balancer or CDN configuration layer
- Implement HSTS with a of at least 31536000 seconds, and include and directives
- Validate your TLS configuration against OWASP TLS Cheat Sheet using Qualys SSL Labs (target A+ rating) before launch
- Automate certificate renewal using Let's Encrypt with Certbot or your cloud provider's managed certificate service - manual renewal is an operational risk
See the related guide on Zero Trust Network Architecture for SaaS for broader network security posture recommendations.
How Do Third-Party Dependencies Introduce Critical Vulnerabilities You Did Not Write?
Third-party dependency vulnerabilities (OWASP A06:2021) are the highest-frequency category in this list - appearing in approximately 96% of pre-launch SaaS applications in Seven Labs VAPT engagements. CVSS scores for known dependency vulnerabilities range from 5.0 to 9.8, and critically, these are publicly known vulnerabilities with published CVEs and working exploit code. CVE-2021-44228 (Log4Shell, CVSS 10.0) demonstrated the industrial-scale impact of a single dependency vulnerability.
The risk is not the existence of dependencies - it is the absence of a dependency management process. A startup with 847 npm packages (a typical Node.js SaaS) and no automated scanning has no visibility into which of those packages currently carries a critical CVE.
Remediation steps:
- Run , , or in your CI pipeline as a required step - fail the build on critical-severity findings
- Implement automated dependency scanning with Dependabot (GitHub), Snyk, or OWASP Dependency-Check
- Pin direct dependencies to specific versions; regularly review and update; do not assume that is automatically secure
- Audit your software bill of materials (SBOM) before launch using tools like Syft or CycloneDX to understand your full transitive dependency tree
Why Does Insufficient Logging Make Every Other Vulnerability on This List More Dangerous?
Insufficient logging and monitoring (OWASP A09:2021, CVSS 6.0–7.5) does not enable attacks directly - it disables your ability to detect and respond to them. In Seven Labs VAPT engagements, approximately 93% of pre-launch SaaS applications lack sufficient logging to detect an active attack or reconstruct a breach timeline after the fact. The average dwell time for an attacker inside a compromised environment is 207 days [Source: Verizon DBIR 2025]. Without adequate logging, that window is effectively unlimited.
What "sufficient" logging means for a pre-launch SaaS:
- Authentication events (login success, failure, MFA bypass) with user ID, IP, timestamp, and user-agent
- Authorization failures - every from your access control layer, logged with the resource that was requested and the identity that requested it
- Administrative actions - account privilege changes, bulk data exports, API key generation
- Anomalous data access patterns - requests that match enumeration behavior (sequential IDs, high-frequency low-latency patterns)
Remediation steps:
- Centralize logs in an immutable, append-only log management system (AWS CloudWatch, Datadog, Elastic) before launch - not after an incident
- Define and implement alert rules for authentication anomalies and authorization failure spikes before go-live
- Ensure logs do not contain sensitive data (passwords, tokens, full PII) - log identifiers and event types, not payload contents
- Test your detection capability during the VAPT engagement itself: verify that the simulated attack attempts generate the alerts you expect
"The logging gap is almost universal in pre-launch SaaS. Companies spend significant effort securing the perimeter and nothing on their ability to know when that perimeter has been crossed." - James Kettle, Principal Researcher, PortSwigger Web Security
How Does Seven Labs Run a Pre-Launch VAPT Engagement?
Seven Labs VAPT engagements for SaaS startups typically run 3 to 12 days, scaled to application complexity and scope. The methodology combines grey-box assessment (authenticated access to the application, access to architecture documentation, but no direct source code access) with targeted white-box review of specific high-risk components identified during reconnaissance.
Phase 1 - Threat Modeling and Scope Definition (Day 1) Before testing begins, Seven Labs maps the attack surface: authentication flows, data classification, third-party integrations, and infrastructure topology. This determines where testing effort is concentrated and what out-of-scope systems need explicit boundaries.
Phase 2 - Automated Scanning Baseline (Days 1–2) Automated tools (OWASP ZAP, Nuclei, Nessus, custom tooling) establish the baseline vulnerability landscape. Automated scanning finds the high-frequency, low-complexity findings - missing headers, TLS configuration issues, known CVEs in identified software versions. This phase informs manual testing priorities.
Phase 3 - Manual Penetration Testing (Days 2–9) Manual testing covers the vulnerability categories in this guide. Every access control boundary is tested for BOLA and IDOR. Every authentication endpoint is tested for rate limiting, brute-force protection, and session management. API responses are analyzed for data exposure. JWT implementations are reviewed and tested for known bypass techniques. This is the phase that surfaces the findings automated scanning cannot reach - business logic flaws, chained vulnerabilities, and context-dependent access control bypasses.
Phase 4 - Reporting and Remediation Roadmap (Final Day) Every vulnerability is documented with CVSS severity rating, proof-of-concept reproduction steps, business impact assessment, and a specific remediation action - not generic advice. Clients receive a prioritized remediation roadmap organized by risk tier, with high-severity findings accompanied by the specific code change or configuration update required.
Seven Labs delivers every vulnerability documented with clear severity ratings and remediation steps that engineering teams can action from day one. Learn more about the full engagement process: VAPT & Penetration Testing Services.
For additional context on how structured VAPT prevents catastrophic outcomes: How VAPT Audits Prevent Disaster and VAPT Security Threats.
Frequently Asked Questions
How long does a pre-launch VAPT engagement take for a SaaS application?
Most pre-launch SaaS VAPT engagements run between 3 and 12 days depending on application scope, number of API endpoints, and infrastructure complexity. Smaller applications with defined scope can complete a grey-box assessment in three to five days. Comprehensive assessments covering infrastructure, application layer, and third-party integrations typically require eight to twelve days.
What is the difference between a vulnerability assessment and a penetration test for SaaS?
A vulnerability assessment identifies and classifies known weaknesses using automated scanning and manual review. A penetration test actively attempts to exploit those weaknesses to determine real-world impact and blast radius. SaaS applications require both: assessment establishes coverage breadth, penetration testing validates actual exploitability and chains vulnerabilities that scanners cannot connect.
Which vulnerability in this list is most commonly missed by internal engineering teams?
Broken Object Level Authorization (BOLA/IDOR) is consistently the most-missed vulnerability in internal security reviews. It does not appear in automated scanners reliably, it requires understanding business context to identify, and it tends to accumulate silently as API endpoints are added over time without systematic access control review at the object level.
When is the right time to run a VAPT engagement for a SaaS startup?
The highest-value timing is four to eight weeks before launch - late enough that the application is feature-complete and the attack surface is stable, early enough that critical findings can be remediated before the application is publicly accessible. Running VAPT after launch means vulnerabilities exist in a live environment with real user data during the remediation window.
Schedule Your Pre-Launch Security Audit
If your SaaS application is within 90 days of launch and has not undergone a structured security assessment, you are likely carrying several of the vulnerabilities in this guide without knowing it. Thomas E. and his team in Sweden discovered 11 critical vulnerabilities they had completely missed - after a Seven Labs VAPT engagement, they had a remediation roadmap they could action from day one.
A pre-launch VAPT engagement is the most cost-effective security investment available to an early-stage SaaS company. The cost of a structured assessment is a fraction of a single breach, and the findings are specific enough to act on immediately.