Table of Contents

1. Executive Summary
2. Scope and Methodology
3. Findings Summary
4. Detailed Findings (2 of 13 shown)
5. Brand Protection Snapshot
6. Retest Results
7. Compliance Evidence Package
8. Appendix
9. Disclaimer

Executive Summary

Cyber Secify Consulting Pvt Ltd was engaged by Acme SaaS Pvt. Ltd. to conduct a grey-box penetration test of their primary SaaS platform and its supporting API infrastructure. The engagement covered two scopes: the web application at app.acmesaas.io (Scope 1) and the REST API at api.acmesaas.io/v2 (Scope 2). Testing was conducted between 12 February 2026 and 21 February 2026 over a period of 10 calendar days (7 days for the primary web application, 3 days for the API).

The assessment was performed by a senior team led by Rathnakara GN (OSCP, CompTIA PenTest+) and Ashok S Kamat, following the OWASP Web Security Testing Guide (WSTG) v5.0, OWASP Application Security Verification Standard (ASVS) 4.0.3, and the Penetration Testing Execution Standard (PTES). The testing approach combined manual exploitation with automated scanning, focusing on business logic flaws, privilege escalation, and chained attack scenarios that automated tools typically miss.

Key Statistics

Business Impact Summary

The most significant risk to Acme SaaS is the combination of an Insecure Direct Object Reference (IDOR) vulnerability in the billing API and a broken authentication flaw in the API token refresh mechanism. Together, these findings mean that any authenticated user on the platform can access billing records belonging to other organisations, and a compromised or expired token can be refreshed indefinitely without re-authentication. For a B2B SaaS platform handling financial transactions, these represent direct threats to customer trust, regulatory compliance, and revenue.

If exploited, the IDOR vulnerability alone could expose the billing records (names, addresses, invoice amounts, partial payment details) of every organisation on the platform. This would likely trigger mandatory breach notification obligations under India's Digital Personal Data Protection Act and, for any EU-based customers, under GDPR. The reputational cost to a SaaS company during a fundraise or enterprise sales cycle could be substantial.

Top 3 Priority Findings

Strategic Recommendation

We recommend Acme SaaS treat the two critical findings as P0 incidents and remediate them before the next production release. The billing API IDOR requires adding server-side organisation-level authorization checks (estimated effort: 2 to 4 hours of engineering time). The SQL injection requires migrating the search endpoint to parameterized queries (estimated effort: 4 to 8 hours). Once these are resolved, the remaining high and medium findings should be addressed within the next two sprint cycles. The compliance evidence package (Section 7) maps all findings to SOC 2 and ISO 27001 controls, which will be directly useful for Acme SaaS's upcoming SOC 2 Type 2 audit preparation.

Scope and Methodology

In-Scope Targets

Testing Approach

Grey-box testing was performed with authenticated access. The Acme SaaS engineering team provided two sets of credentials: a standard user account (Member role) and an administrator account (Admin role). This approach simulates both external attacker scenarios (credential compromise, account takeover) and insider threat scenarios (malicious or compromised employee).

Manual testing was the primary method. Automated scanning was used to supplement coverage and identify common misconfigurations, but all critical and high findings in this report were discovered through manual analysis and exploitation. Business logic testing, privilege escalation, and chained-attack scenarios were performed manually.

Methodology and Standards

Tools Used

Out of Scope

Denial-of-service testing, social engineering, physical security assessments, and testing against third-party SaaS integrations (Stripe, AWS Cognito) were excluded from this engagement. All testing followed responsible disclosure practices.

Findings Summary

Severity Distribution

Scope 1 Findings: Web Application (app.acmesaas.io)

Scope 2 Findings: REST API (api.acmesaas.io/v2)

Detailed Findings

Two of 13 findings are shown in full below. The remaining 11 findings follow the same format in the complete report.

GET /api/v2/billing/invoices/INV-2026-00098 HTTP/1.1
Host: api.acmesaas.io
Authorization: Bearer eyJ0eXAi...[REDACTED]
X-Org-Id: org_acme_test_001
Accept: application/json

{
  "invoice_id": "INV-2026-00098",
  "org_id": "org_different_company",
  "org_name": "[REDACTED]",
  "billing_email": "[REDACTED]@company.com",
  "amount": 24999.00,
  "currency": "INR",
  "plan": "Growth Annual",
  "payment_method": "**** **** **** 4832",
  "billing_address": {
    "line1": "[REDACTED]",
    "city": "[REDACTED]",
    "state": "[REDACTED]",
    "postal_code": "[REDACTED]"
  },
  "status": "paid",
  "issued_date": "2026-01-15"
}

// middleware/authorizeInvoice.js
const authorizeInvoice = async (req, res, next) => {
  const invoice = await Invoice.findById(req.params.invoiceId);

  if (!invoice) {
    return res.status(404).json({ error: "Invoice not found" });
  }

  // Verify org-level ownership
  if (invoice.orgId !== req.auth.organisationId) {
    logger.warn("IDOR attempt", {
      userId: req.auth.userId,
      requestedInvoice: req.params.invoiceId,
      userOrg: req.auth.organisationId,
      invoiceOrg: invoice.orgId
    });
    return res.status(403).json({
      error: "Forbidden: insufficient permissions"
    });
  }

  req.invoice = invoice;
  next();
};

POST /api/v2/auth/token/refresh HTTP/1.1
Host: api.acmesaas.io
Content-Type: application/json
Authorization: Bearer eyJ0eXAi...[EXPIRED ACCESS TOKEN]

{
  "refresh_token": "rt_[REDACTED]...expired_8_days_ago"
}

{
  "access_token": "eyJ0eXAi...[NEW VALID TOKEN]",
  "token_type": "Bearer",
  "expires_in": 900
}

async function refreshToken(req, res) {
  const { refresh_token } = req.body;

  // 1. Validate refresh token exists and is not expired
  const storedToken = await RefreshToken.findOne({
    token: refresh_token,
    expiresAt: { $gt: new Date() },
    revoked: false
  });

  if (!storedToken) {
    return res.status(401).json({ error: "Invalid or expired refresh token" });
  }

  // 2. Verify user account is still active
  const user = await User.findById(storedToken.userId);
  if (!user || !user.isActive) {
    await RefreshToken.revokeAll(storedToken.userId);
    return res.status(401).json({ error: "Account deactivated" });
  }

  // 3. Check if password changed after token was issued
  if (user.passwordChangedAt > storedToken.issuedAt) {
    await RefreshToken.revokeAll(storedToken.userId);
    return res.status(401).json({ error: "Password changed, re-authenticate" });
  }

  // 4. Rotate: revoke old token, issue new pair
  await storedToken.revoke();
  const newTokens = generateTokenPair(user);
  return res.json(newTokens);
}

Brand Protection Snapshot

As part of every penetration testing engagement, Cyber Secify Consulting Pvt Ltd performs a Brand Protection Snapshot during the reconnaissance phase. This assessment covers external threats to Acme SaaS's brand and digital identity that fall outside the application scope but directly affect overall security posture and customer trust.

Domain and Typosquatting Analysis

We checked 14 common typosquatting variations of acmesaas.io, including character transpositions, homoglyph substitutions, and TLD variations.

Leaked Credentials Check

We queried breach databases and dark web marketplaces for credentials associated with acmesaas.io email domains.

Recommendation: Force password resets for the affected accounts immediately. Enforce MFA for all employee accounts. Cross-reference these credentials against internal systems to check for password reuse.

Code Exposure

We scanned public GitHub repositories, GitLab instances, and Pastebin for code or configuration files referencing acmesaas.io.

Fake App Detection

We monitored the Google Play Store, Apple App Store, and third-party APK repositories for applications impersonating Acme SaaS.

Social Media Impersonation

We scanned LinkedIn, X (Twitter), and Facebook for profiles or pages impersonating Acme SaaS or its founders.

Retest Results

The Growth Pentest Plan includes two retests: a full retest after the first round of remediation, and a sanity retest after final fixes. Both retests were conducted within the 30-day remediation window.

First Retest (Full Retest)

Date: 10 March 2026. Conducted by: Rathnakara GN.

The Acme SaaS engineering team remediated 11 of 13 findings. All critical and high findings were addressed except for CS-2026-010 (Broken Authentication on Token Refresh) and CS-2026-013 (API Versioning Endpoint Leaks Deprecated Routes). Both were scheduled for the next sprint.

Second Retest (Sanity Retest)

Date: 21 March 2026. Conducted by: Rathnakara GN.

The Acme SaaS team deployed fixes for the two remaining open findings. The sanity retest confirmed that both are now resolved.

Compliance Evidence Package

The tables below map all pentest findings to relevant SOC 2 and ISO 27001 controls. This section is formatted for direct inclusion in your audit evidence package. Hand these tables to your auditor as evidence of penetration testing, findings, and remediation.

SOC 2 Control Mapping

ISO 27001 Control Mapping

Appendix

A. Tools and Versions

B. Testing Team Credentials

C. Report Distribution

D. Glossary

Disclaimer

Penetration testing is inherently limited by the scope, time, and resources allocated to the engagement. Therefore, no individual or organization can guarantee identifying all security issues. The testing we performed is conducted on a best-effort basis, and the findings reported herein are specific to the environment provided for testing.

The dynamic nature of technology and the constant evolution of new attack techniques mean that security assessments can only provide a snapshot of the current security posture.

Limitations of Testing

The reported findings apply exclusively to the tested environment and configurations during testing. Information systems rely on human factors and can be inherently vulnerable to human error. While we have endeavoured to identify significant security vulnerabilities in the analysed applications, it is impossible to assure that all potential vulnerabilities have been discovered.

Scope of Findings

The recommendations provided are based on the information, technologies, and known threats as of the date of this report. As technologies and risks evolve, so will the nature of vulnerabilities and the necessary mitigation measures.

Continued Vigilance

Security is an ongoing process. Regular assessments and updates to security measures are essential to maintaining a strong security posture. We recommend periodic penetration testing and continuous monitoring to adapt to new threats and vulnerabilities.

By accepting this report, you acknowledge the testing's inherent limitations and understand the necessity of ongoing security vigilance.