API Security Testing in Bengaluru · SaaS & Product APIs

Bengaluru ships products, and a Bengaluru product is an API surface. The B2B SaaS belt along the Outer Ring Road, the GCC product orgs in Whitefield and the deep-tech startups around Koramangala and Indiranagar all live or die on multi-tenant REST and GraphQL APIs that customers integrate against. Macksofy tests those APIs the way your largest enterprise customer's security team will when they run their own assessment before signing — because in Bengaluru, the API pentest report is increasingly a sales artifact, not just a compliance one.

The defining risk for a Bengaluru SaaS API is tenant isolation. We anchor on the OWASP API Security Top 10 (2023), and for multi-tenant products the headline finding is BOLA (API1) across the tenant boundary — a token scoped to tenant A reaching tenant B's records by manipulating an object or organisation identifier. We test with two tenants and two roles per tenant, so cross-tenant and cross-role authorization are both proven, not assumed. Broken object-property-level authorization (API3) — mass-assigning a `role`, `plan` or `tenant_id` field, or excessive data exposure returning internal fields the UI never shows — is the next seam, and it is everywhere in fast-moving product code.

GraphQL gets first-class treatment because so much of Bengaluru runs it. We test introspection exposure, query depth and aliasing/batching abuse (an unrestricted-resource-consumption vector that can take a cluster down or drive cloud spend), field- and edge-level authorization, and the same cross-tenant BOLA logic applied to resolvers and node lookups. For REST microservice meshes we test east-west trust assumptions — the internal service that trusts a header the gateway was supposed to strip — and the service-to-service auth that product teams often leave implicit.

Bengaluru engagements are CI/CD-shaped. We integrate where it helps — running authenticated API scans against an ephemeral preview environment, wiring a Nuclei/ZAP baseline into the pipeline so regressions are caught pre-merge — but the depth comes from manual abuse-case testing a pipeline cannot do: business-flow abuse (API6) on trials, invites, billing and usage-metering; SSRF (API7) on the webhook-registration and integration-connector features that every SaaS ships; and unsafe consumption of third-party APIs (API10) where your product trusts a partner response it shouldn't. We test against staging with production-like data shape, and we move at the cadence of a team that deploys daily.

The deliverable is built to clear two gates at once: the customer security questionnaire and the audit. Findings map to SOC 2 (CC-series), ISO 27001:2022 Annex A, and India's DPDP reasonable-security-safeguards expectation, and the report is written so your buyer's security reviewer reads it as evidence of maturity rather than a list of holes. Improper inventory management (API9) — the undocumented internal endpoint, the deprecated `/v1` still serving — is reported with a gateway-governance plan, because for a product company an unknown API is an unmanaged liability and a future incident.

Re-testing is included in the SoW inside a 60-day window, and we deliver a clean re-test letter your sales and compliance teams can forward to prospects. We are vendor-neutral on the gateway stack — Kong, Apigee, AWS API Gateway, Azure APIM, Envoy/Istio — and we don't resell any of it, which matters when we're also recommending how to configure it. Onsite is straightforward across ORR, Whitefield, Electronic City and Manyata; most product engagements run remote-first with a kickoff and a findings-walkthrough working session with your engineering leads.