SaaS & Developer Platforms

    API Security Testing for SaaS Platforms and Multi-Tenant Applications

    Multi-tenant SaaS platforms have one dominant vulnerability class: tenant data isolation failures. When object-level authorization is missing or inconsistently applied across your API, one tenant's user can query another tenant's data by changing a resource ID in the request. This is the most common critical finding in SaaS API security reviews.

    ApyGuard tests every tenant-scoped endpoint for cross-tenant access on every pull request -- so authorization regressions are caught before they merge, not after a customer reports them.

    The Multi-Tenant Authorization Problem

    A typical SaaS API endpoint looks like this: GET /api/workspaces/{workspaceId}/projects. The intent is that users can only access workspaces they belong to. The implementation checks: does this user's JWT contain a valid workspace ID? It does not always check: does the workspace ID in the URL match the one in the JWT?

    An attacker -- or a curious user -- who discovers this pattern can enumerate workspace IDs and access every tenant's projects. No special exploit required. Just replace the ID in the URL.

    This pattern repeats across every resource type in a SaaS platform: organizations, teams, projects, files, billing records, audit logs. A single BOLA vulnerability can expose not just one resource but every resource of that type across all tenants in your database.

    What ApyGuard Tests in SaaS APIs

    Six testing categories cover the SaaS-specific vulnerability surface. All run on every deployment.

    API1
    Cross-tenant BOLA testing

    ApyGuard tests every tenant-scoped endpoint with requests that substitute one tenant's resource IDs for another's. If your authorization layer relies on the tenant ID in the JWT rather than checking it against the requested resource, we find it.

    API2
    API key scope enforcement

    Tests whether API keys are scoped to specific resources, operations, or tenants as intended. Checks for key A accessing resources owned by key B's account, missing scope validation, and overly permissive default scopes.

    API3
    Mass assignment on role and plan fields

    Account update and user management endpoints are tested for mass assignment vulnerabilities -- can a standard user set their own role to admin, change their subscription plan, or unlock feature flags by including extra fields in the request body?

    API5
    BFLA on admin and tenant management endpoints

    Tenant administration endpoints (suspend account, change plan, access all tenant data) are tested with standard user credentials. If your RBAC is enforced at the UI layer rather than the API layer, BFLA testing finds it.

    API4
    Rate limiting on usage-based endpoints

    Usage-based SaaS platforms are vulnerable to resource exhaustion attacks. ApyGuard verifies rate limits are enforced on data export, bulk operation, and API usage endpoints that directly affect your infrastructure costs.

    API8
    Security misconfiguration

    Checks for missing authentication on internal endpoints, verbose error responses that expose tenant data or stack traces, open CORS policies that allow cross-origin access from arbitrary domains, and default credentials on admin interfaces.

    Developer-Facing APIs Are a Different Attack Surface

    APIs built for developers are designed to be expressive and flexible. That design goal creates security problems: developer APIs tend to accept more fields than documented, expose more query parameters than intended, and return more data than the client asked for.

    A customer using your UI sees a curated interface. A developer using your API sees the raw surface -- and so does an attacker. ApyGuard tests your API the way an attacker would: sending undocumented parameters, combining permissions from different roles, probing error responses for information leakage.

    If you publish a public API (webhooks, integrations, platform API), use the ApyGuard browser extension to capture all active endpoints before scanning. Public developer documentation rarely covers every route your API exposes.

    Catch Authorization Regressions at the Pull Request

    SaaS authorization regressions happen at the code level. The right place to catch them is before the merge, not after the deployment.

    1

    Developer opens a pull request

    Any PR touching API handlers, middleware, or authorization logic triggers the scan.

    2

    ApyGuard scans the staging deployment

    The pentest action deploys against your PR's staging URL and runs the full OWASP Top 10 suite.

    3

    Findings appear as PR checks

    Critical and high findings fail the check. Medium and low findings are reported without blocking merge.

    4

    Developer fixes and re-scans

    Fix the finding, push the commit, and the scan runs again automatically. Clean scan unblocks the merge.

    .github/workflows/api-security.yml
    - name: API Security Scan
     uses: apyguard/pentest-action@v1
     with:
     api-spec: ./openapi.yaml
     api-url: ${{ secrets. STAGING_API_URL }}
     api-key: ${{ secrets. APYGUARD_KEY }}
     fail-on: high
     tenants: 2

    Monitor API Behavior After Deployment

    Penetration testing verifies that your API was secure at the time of the scan. APIs change after deployment -- schema migrations, new integrations, dependency updates, configuration changes. A response field that was absent last week can appear today.

    After pentesting with ApyGuard, use behavior profiling to run daily authenticated scans against your deployed API. Any change in response shape, status code, or sensitive data triggers an alert -- catching the regressions that deploy after the pentest gate.

    Frequently Asked Questions

    How do you test cross-tenant access with only one test account?

    ApyGuard creates multiple test identities during scan setup -- a primary user and a secondary user in a separate tenant. BOLA tests send requests from the primary user's session attempting to access resources registered to the secondary tenant. You provide credentials for both during configuration.

    Can ApyGuard test multi-region SaaS deployments?

    Yes. You configure a target URL for each environment. If your regions share the same API codebase, one scan covers all regions. If regions have different infrastructure (data residency deployments), you can configure separate scan targets for each.

    What's the performance impact of a scan on staging?

    ApyGuard sends HTTP requests at a controlled rate -- typically equivalent to a moderate load test. Scans are designed for staging environments, not production. Most SaaS teams run scans against feature branch staging deployments where load impact is not a concern.

    Can we test the API as different user roles?

    Yes. You provide credentials for each role you want tested -- standard user, team admin, super admin. ApyGuard tests BFLA by attempting to access higher-privilege functions with lower-privilege credentials, and BOLA by testing cross-role resource access.

    Related industries

    Explore similar authorization challenges

    These industries face overlapping API risks around object-level authorization, role boundaries, and sensitive workflow abuse.

    Test Your Multi-Tenant API on Every Deployment

    Connect your API spec and run your first cross-tenant authorization test in under 30 minutes. No credit card required.

    Read the API security best practices guide.