How to detect vulnerabilities in a SaaS application

To detect vulnerabilities in a SaaS application, combine four layers: automated analysis in the development cycle (code, dependencies and configuration), dynamic testing against a deployed environment, manual tests focused on authorisation and isolation between customers, and continuous monitoring. Prioritise by real-world exploitability and repeat the cycle with every release.

Why a SaaS application is different

A SaaS application concentrates many customers' data on the same platform, ships often and integrates with other systems through APIs. That shifts the risk to three places:

• Access control. Broken Access Control is the first category of the OWASP Top 10:2025 [1], and Broken Object Level Authorization is risk number one in the 2023 OWASP API Security Top 10 [2]. Both describe the same pattern: an authenticated user reaches data that is not theirs by changing an identifier.
• Tenant isolation. OWASP's guidance on multi-tenant systems recommends treating client-supplied tenant identifiers only as selectors (they do not prove access) and verifying the user's membership of the tenant before setting the context [3].
• Supply chain and deployment. The Top 10:2025 includes software supply chain failures and security misconfiguration among its categories [1].

Step 0: inventory and scope

You cannot test what you do not know. Before choosing tools, gather:

• Domains, subdomains and environments (production, staging, demos).
• Every API, public and internal, and its specification (for example, OpenAPI).
• Roles and user types, including customer administrators and your own support staff.
• Third-party dependencies. According to CISA, a software bill of materials (SBOM) is a nested inventory of the components that make up software [4].

The four layers of detection

Layer 1: security inside the development cycle

NIST's SSDF (SP 800-218) proposes a core set of secure development practices that can be integrated into any software development life cycle to reduce the vulnerabilities in what you release [5]. In practice, that means blocking the merge when a secret appears in the repository, a dependency carries an exploited vulnerability or a cloud configuration is insecure.

Layer 2: dynamic and API testing

The API specification is the best starting point for automation. As a methodological reference, OWASP presents its Web Security Testing Guide as the premier cybersecurity testing resource for web developers and security professionals; its current stable version is 4.2 [6]. Automated tools find what is repeatable well; what they do not find is your business logic.

Layer 3: manual authorisation and isolation testing

This is the layer no tool replaces in a SaaS. A simple procedure:

1. Create two test tenants with different data and, in each, users of every role.
2. With a user from tenant A, try to read, modify and delete tenant B's objects by changing identifiers in the URL, the body, the headers and the queries.
3. Repeat with a lower role inside the same tenant (a regular user calling administrator functions).
4. Check that bulk operations, exports and searches respect the tenant.
5. Run the tests through the same path the real application uses (same database role, same connection pool): OWASP's guidance warns that a privileged test connection can hide real bypasses [3].
6. If you use row-level security in the database, verify that the role the application uses is not a superuser and does not bypass the policies [3].

Standards help you not forget anything: ASVS 5.0 is OWASP's framework of security requirements for designing, developing and testing modern web applications and web services [7]. You can use it as a checklist to decide what to test.

Layer 4: continuous monitoring

The Top 10:2025 devotes a category to security logging and alerting failures [1]: without useful logs it is hard to detect exploitation. Log authorisation denials, permission changes and cross-tenant data access, and subscribe to a source of exploited vulnerabilities, such as CISA's KEV catalogue [8], to cross-check against your dependencies.

How to prioritise what you find

CVSS scores the technical severity of a vulnerability (the current version is 4.0) [9], but it does not say whether anyone is exploiting it. Combine three signals:

1. Technical severity (CVSS).
2. Likelihood of exploitation: EPSS estimates the probability that a published CVE will be exploited [10], and the KEV catalogue lists those already exploited [8].
3. Your own context: is it exposed to the internet? Does it affect several customers' data? Is there a compensating control?

An authorisation flaw that exposes data between customers usually goes ahead of a high-severity one in a component that cannot be reached from outside.

A reasonable working rhythm (illustrative)

This is an indicative proposal; adjust the cadence to your risk and your contractual obligations.

Which evidence to keep

Your customers and auditors will want results, not intentions: the latest pentest report with scope and methodology, a findings table with status and fix dates, a disclosure policy and patching deadlines, and retest results. Keep them versioned.

How we help

Hodeitek delivers pentesting and Red Team, with web application testing as one of its lines. If you are unsure which you need, see Red Team vs Pentest: When to Use Each One and Why the Difference Matters. If you want a free first look from the outside, you can ask about places in the external radar. For continuous watch there is the managed SOC (SOCaaS / MDR) service, and if you need evidence for customers and auditors, GRC consulting. For the protection layer at the edge, read how WAAP platforms handle zero-day attacks without false positives.

Frequently asked questions

How to detect vulnerabilities in a SaaS application?

By combining several techniques, because no single one is enough. Code and dependency analysis, dynamic testing and manual testing find different things; cross-tenant access control is the area where manual testing adds the most.

How often should I run a pentest?

At least once a year and before major releases or architecture changes; in between, the automated layers on every change. This is an indicative guideline, not a universal obligation.

Which vulnerabilities are most common in a SaaS?

Access control flaws top both the 2025 web application Top 10 [1] and the 2023 API security Top 10 [2]. That is why you should always test authorisation between tenants and between roles.

Does an automated scanner satisfy a customer who asks for a pentest?

Usually not: a scanner is a detection layer, whereas a pentest involves manual testing with documented scope and methodology. Check it against the specific contractual requirement.

How do I prioritise if I find hundreds of findings?

Combine severity (CVSS [9]), likelihood of exploitation (EPSS [10] and KEV [8]) and your context: exposure, affected data and compensating controls.

Next step

Do you want us to test your SaaS from an attacker's perspective? Tell us the scope. And if your customers ask you for security evidence as a supplier, get to know HodeiShield, our platform for managing, controlling and tracing the supply chain and compliance.

Sources

1. OWASP Top 10:2025. OWASP. https://top10.owasp.org/2025/en/
2. OWASP API Security Top 10 (2023). OWASP. https://api-security.owasp.org/editions/2023/en/0x11-t10
3. Multi-Tenant Security Cheat Sheet. OWASP Cheat Sheet Series. https://cheatsheetseries.owasp.org/cheatsheets/Multi_Tenant_Security_Cheat_Sheet.html
4. Software Bill of Materials (SBOM). CISA. https://www.cisa.gov/sbom
5. Secure Software Development Framework (SSDF) Version 1.1 (SP 800-218). NIST. https://csrc.nist.gov/pubs/sp/800/218/final
6. Web Security Testing Guide. OWASP. https://owasp.org/www-project-web-security-testing-guide/
7. Application Security Verification Standard (ASVS) 5.0. OWASP, 2025-05-30. https://asvs.owasp.org/
8. Known Exploited Vulnerabilities Catalog. CISA. https://www.cisa.gov/known-exploited-vulnerabilities-catalog
9. Common Vulnerability Scoring System (CVSS). FIRST. https://www.first.org/cvss/
10. Exploit Prediction Scoring System (EPSS). FIRST. https://www.first.org/epss/