The following narrative shows our testing approach and the most critical findings - anonymized, but detailed enough to illustrate our methodology and the severity of the risks.
Phase 1: Mapping the Attack Surface
We began with a systematic analysis of the SaaS platform from an attacker's perspective. With access to a regular user account, we first mapped all functionality: What features exist? Which API endpoints are called? Where is sensitive data processed?
The platform followed a modern Single Page Application architecture: A React frontend (Next.js) communicating via a RESTful API with a Django backend. Typical for SaaS systems, there were several critical functional areas we prioritized:
- User Management: Account creation, profile changes, password resets
- Organization Management: Multi-tenant architecture with org switching
- Data Access: AI governance data, risk assessments, compliance reports
- Admin Functions: User administration, permissions, system settings
Our experience shows: For SaaS platforms, the most critical vulnerabilities typically lie in authentication and authorization logic as well as tenant isolation. We focused our testing precisely here.
Phase 2: Session Management Vulnerabilities
When analyzing the authentication flow, we tested a critical scenario: What happens when a user makes sensitive account changes? In security-critical systems, certain actions - such as email changes or password resets - should invalidate all existing sessions to prevent session hijacking attacks.
We set up a test scenario: Two browser sessions with the same user account. In Session A, we changed the account's email address. Then we checked Session B: Was this session still active?
Result: Critical finding. The old session remained fully functional. An attacker who had temporarily gained access to a session (through XSS, man-in-the-middle, phishing, or physical access) could maintain that access - even after the victim changed their password.
Business Impact: Account Takeover
This vulnerability enabled account takeover scenarios. An attacker with brief session access could:
- Maintain access even after password change
- Access sensitive AI governance data
- Cause compliance violations (GDPR Art. 32)
- Damage trust with enterprise customers
Root Cause: The implementation relied on frontend logic for session invalidation. The backend did not proactively validate all existing sessions during critical account changes. This is a classic example of a business logic vulnerability that automated scanners cannot find - but that real attackers would exploit.
Phase 3: Authorization Bypass Through Missing Backend Validation
Next, we tested the authorization logic. For multi-user systems, the crucial question is: Can a user access data or functions that don't belong to them?
We analyzed the API calls made when accessing various features. In user management, we noticed: The API accepted user IDs as parameters. Classic test case for Broken Object Level Authorization (BOLA) - one of the most common API vulnerabilities according to OWASP API Security Top 10.
We tested whether we could access other users' data by manipulating the user ID in the API request. Multiple endpoints were vulnerable. The frontend application only displayed valid IDs, but the API endpoints did not sufficiently validate server-side whether the requesting user was authorized to access the requested data.
This enabled Horizontal Privilege Escalation: A regular user could access data from other users in the same organization. For sensitive AI governance data, this is a clear GDPR violation and breach of trust.
Why Scanners Don't Find This
Automated tools only see what's visible in the frontend. They "click" through the app like a normal user. Authorization bypasses through API parameter manipulation require manual analysis of API logic, understanding of business rules, and targeted testing of edge cases.
Phase 4: Input Validation Gaps
We systematically tested input validation at various entry points. Modern frameworks like React offer some protection against XSS through automatic escaping. Nevertheless, we found several places where validation was insufficient.
Particularly problematic: The platform used client-side validation for critical inputs without repeating this server-side. An attacker can trivially bypass client validation - either through direct API calls (e.g., with curl or Burp Suite) or by manipulating JavaScript code in the browser.
We identified several endpoints potentially vulnerable to SQL Injection or Command Injection because backend validation was missing. While Django's ORM fundamentally protects against SQL injection, improper use of raw queries or dynamic filters can introduce vulnerabilities.
Phase 5: Excessive Data Exposure in APIs
A common problem in API-first architectures: APIs return more data than the frontend needs. Developers often implement "universal" API endpoints that return complete object structures, even though the frontend only displays certain fields.
We analyzed the API responses and found several endpoints containing sensitive data that wasn't displayed in the frontend - but was visible to anyone querying the API directly. This included internal IDs, technical metadata, and in some cases even data from other organizations.
The principle should be: APIs only return what the client needs and the user is allowed to see. Every additional field is a potential information disclosure.
What Impressed Us: Security Awareness
Despite the vulnerabilities found, it was evident that the team takes security seriously: The architecture was fundamentally solid, modern frameworks were used, HTTPS was implemented everywhere, and many best practices were already in place. The vulnerabilities found were typical for fast-growing scale-ups: gaps in implementation depth, not fundamental architectural flaws.
That's precisely why remediation was so successful: The team immediately understood the findings and implemented systematic fixes.
