The 6 Most Common Vulnerabilities We Actually Find in Indian SME Web Apps

Most SME web apps in India aren't broken into by a sophisticated attacker with a zero-day. They're broken into because of one of six patterns that show up so often we could recite them before opening the code. None of these need a nation-state adversary — most were found with a browser's dev tools and about ten minutes of poking around.

1. Broken access control (IDOR)

The single most common finding in every assessment we run. An endpoint like /api/invoices/1042 returns invoice #1042's data based on nothing but the number in the URL — no check that the logged-in user is actually allowed to see invoice #1042. Change the number to 1043, get someone else's invoice.

This happens because it's the easiest way to write the endpoint, and it works perfectly in every test where the developer is logged in as themselves. It only breaks when someone tries a number that isn't theirs — which is exactly what nobody does in normal QA, and exactly what an attacker does first.

Fix: every record-fetching endpoint checks ownership server-side, every time, not just at the UI layer that hides the button.

2. No rate limiting on login and OTP endpoints

A login form or an OTP-verification endpoint that accepts unlimited attempts is an invitation to brute-force. We've found OTP endpoints accepting a 4-digit code with no attempt cap — that's 10,000 possible codes, trivially crackable in minutes with a simple script, on an endpoint meant to secure a password reset.

Fix: cap attempts per identifier (5–10 tries), lock or delay after that, and make the lockout apply per account and per IP, not just one or the other.

3. Verbose errors leaking stack traces in production

A request that triggers a server error should return a generic message. Instead, we regularly see full stack traces returned to the browser — file paths, framework versions, sometimes a fragment of a SQL query. None of that is a vulnerability by itself. All of it is a map for finding one: framework version tells an attacker exactly which known CVEs to try, and a SQL fragment can reveal table and column names for free.

Fix: generic error responses in production, full detail only in server-side logs the team can actually see.

4. Unrestricted file uploads

A profile photo or document upload feature that only checks the file extension client-side — or checks nothing at all — will happily accept a .php or .jsp file renamed to look like an image. If that file lands somewhere the web server will execute it, the "photo upload" feature is now a way to run arbitrary code on the server.

Fix: validate file type by content (not filename), enforce a size limit, and store uploads somewhere the web server is configured never to execute — not the same directory serving your application code.

5. Hardcoded secrets shipped in the frontend bundle

Open the browser's dev tools, look at the JavaScript bundle, and search for "key" or "secret." We find live API keys — sometimes for payment gateways or third-party services with real cost implications — sitting in plain text in code that ships to every visitor's browser. Anything bundled into frontend JavaScript is public, permanently, the moment it's deployed, regardless of whether the repository is private.

Fix: any credential that grants access to something costly or sensitive belongs on the server, called through your own backend — never embedded in code the browser downloads.

6. Missing security headers

No Content-Security-Policy, no HSTS, no X-Frame-Options. Individually minor; together, they remove entire categories of built-in browser protection. A missing X-Frame-Options header, for instance, means your login page can be embedded in an invisible iframe on an attacker's site and clickjacked. A missing CSP means a single successful XSS finding goes from "annoying" to "can steal session cookies from every visitor."

Fix: this is a 20-minute change on most modern hosting platforms (Vercel, Netlify, and most reverse proxies support it via config), and it's one of the highest-leverage fixes on this entire list relative to the effort involved.

Why these keep showing up

None of these require deep security expertise to avoid — they require someone to specifically look for them, which rarely happens under a normal ship-fast timeline. A 3–5 day vulnerability assessment exists precisely to catch this list before an attacker does: automated scanning for the mechanical stuff, manual triage so you're not drowning in false positives, and a risk-ranked list of what to fix first.

If you want an honest read on whether your own app has any of these six sitting in it right now, tell us about your setup — a focused assessment is usually faster and cheaper than most founders expect.