By Shouvik Mukherjee — Founder at Bachao.AI, Ex-Principal Engineer
Indian SaaS is growing fast. The engineering is often excellent. The API security is frequently an afterthought — and that gap is getting exploited.
This isn't a lecture. This is a technical walkthrough of what's actually broken, why it keeps shipping, and what you can check on your API today.
Why Indian SaaS APIs Are Disproportionately Exposed
The pattern is consistent: small team, aggressive roadmap, product-market fit as the north star. Security review gets pushed to "after launch." Launch happens, users arrive, engineers move to the next feature. The API surface keeps growing. The security review never happens.
This isn't unique to India, but the scale here is acute. India has tens of thousands of B2B SaaS products shipping at startup pace. Most don't have a dedicated security engineer. Most haven't run a penetration test.
The result: production APIs with real user data, running patterns that OWASP documented as critical years ago.
The OWASP API Top 10 — What's Actually Hitting Indian Products
API1: Broken Object Level Authorization (BOLA)
This is the number one API vulnerability globally — and the most commonly missed in fast-shipping products.
The pattern: your API has an endpoint like GET /api/v1/invoices/{invoice_id}. The backend checks that the user is authenticated. It does not check that the invoice belongs to the authenticated user.
An attacker increments the invoice ID. They access another user's invoice. Then another. Then exports your entire customer dataset by iterating IDs.
This isn't a sophisticated attack. It's a for-loop. And it works on a shocking number of Indian SaaS products.
API3: Broken Object Property Level Authorization
Related but distinct. The API returns more fields than the frontend uses. The mobile app displays user.name and user.email. But the raw API response also contains user.internal_risk_score, user.admin_flag, user.raw_password_hash.
The frontend ignores these fields. A Burp Suite intercept doesn't.
API5: Broken Function Level Authorization
Admin endpoints accessible to regular users. Not because someone intended it — because the route existed and authorization middleware was applied inconsistently.
/api/admin/users/delete returns 403 for most requests. But someone forgot to add the middleware to the /api/v2/admin/ prefix after a refactor. V2 endpoints are open.
API6: Unrestricted Access to Sensitive Business Flows
No rate limiting on OTP generation. No limit on password reset emails. No throttle on the "check if email exists" endpoint.
These aren't just abuse vectors — they're data exfiltration paths. An attacker can enumerate your entire registered user base via a POST /auth/forgot-password endpoint with no rate limit.
API8: Security Misconfiguration
CORS set to *. X-Powered-By: Express 4.18.1. Verbose stack traces in 500 responses. Debug endpoints deployed to production. Old API versions still running (/v1/, /v0/) that were never deprecated.
The Real-World Pattern
Here's a scenario that mirrors actual audit findings — no real company names, but the pattern is real.
A Series A B2B SaaS product. 50,000 users. The engineering team of 12 is competent and moves fast. During a security audit:
-
GET /api/reports/{report_id}— no ownership check. Any authenticated user can pull any report by ID. - The
/api/internal/prefix routes were excluded from auth middleware "temporarily" during a migration six months ago. Never re-added. - The JWT secret:
secretkey. Set during initial dev, never rotated, never changed. - The
/api/v1/and/api/v2/endpoints both active. V1 is deprecated in docs but still running in production — and V1 skips the new input validation added to V2.
None of this was intentional. All of it is the natural result of shipping fast without security checkpoints.
5 Things to Check on Your API Today
1. Test BOLA on your highest-value object endpoints
Pick 3 endpoints that return user-owned resources. Authenticate as User A. Take an ID from User A's response. Swap to User B's auth token. Request User A's resource ID with User B's token. Does it return data? If yes, you have BOLA.
2. Audit your API response objects for over-exposure
For every endpoint, compare what the frontend actually uses versus what the API returns. Any field not consumed by the UI should be explicitly excluded from the response serializer.
3. Check every admin or elevated-privilege route for consistent middleware
List all routes that contain /admin/, /internal/, /superuser/, or equivalent prefixes. Verify auth middleware is applied consistently — not just on the prefix, but on each handler.
4. Test rate limiting on auth endpoints
POST /auth/login — send 100 requests in 60 seconds. Does it throttle? Check OTP, password reset, and account existence check endpoints the same way.
5. Search your codebase for secrets
grep -r "secret|password|apikey|token|AWS_ACCESS" . in your repo. Run git log --all --full-history -- .env to check if .env files were ever committed. This takes 10 minutes and finds critical issues regularly.
The Fix Isn't a Framework — It's a Habit
Most of these vulnerabilities don't require sophisticated tooling to introduce, and they don't require sophisticated tooling to find. They require someone to look.
Security review as a step in the PR process. A threat model conversation when designing a new API. A penetration test before a major launch or a new enterprise customer signs.
If you want a systematic view of your API security posture — not just a scanner report, but actual expert-verified findings — Bachao.AI provides CERT-IN grade API security testing as part of a full VAPT engagement. Free initial scan. You pay only if vulnerabilities are found.
Start at bachao.ai. Know what you're shipping.
Shouvik Mukherjee is Founder & CEO of Bachao.AI, an AI-native end-to-end cybersecurity platform. Ex-Principal Engineer, TEDx Speaker.
Top comments (1)
Insightful article, Shouvik!
Security is one of the most important aspects, yet it’s often pushed to the bottom of the priority list in the rush to ship faster. I’ve personally seen this lead to quite a few issues across codebases.
One additional point, dependency auditing is equally critical. Vulnerabilities can easily creep in through transitive dependencies if they’re not regularly reviewed.