Common App Security Mistakes (with real examples)

Introduction: Why App Security Mistakes Still Happen

Every app today — whether it’s a small startup product or a large-scale platform — handles user data. Logins, emails, phone numbers, payment info… all of it flows through APIs and backend systems.

Now here’s the uncomfortable truth: most security issues don’t come from “advanced hacking.” They come from simple mistakes made during development.

Not because developers are careless, but because:

• Deadlines are tight
• Features are prioritized over security
• Testing focuses on functionality, not abuse
• And sometimes… people assume “no one will try that”

Unfortunately, someone always tries that.

The Mindset Gap

A developer builds like this:

“How should this feature work?”

An attacker thinks like this:

“How can I break this or misuse it?”

That small difference is where most vulnerabilities are born.

Why These Mistakes Matter

These aren’t theoretical issues. In real-world apps, they lead to:

• Account takeovers
• Data leaks
• Unauthorized access
• Full system compromise in worst cases

And the scary part? A lot of these don’t require deep expertise — just observation and basic testing.

What You’re About to See

The following sections focus on common app security mistakes, explained with:

• Practical examples (like what you’d actually see in Burp Suite or logs)
• Why they happen
• What attackers can do with them
• And how they should be fixed

Nothing overly academic. Just real issues that show up again and again in testing.

1) Sending passwords in URLs (GET requests)

This one still shows up more often than it should. Instead of sending login data in the request body, some apps attach it directly to the URL:

GET /login?username=admin&password=123456

At first glance, it “works.” But URLs are logged everywhere — browser history, server logs, reverse proxies, even screenshots and crash reports. That means the password can live in multiple places long after the request is done.

What this leads to:

• Anyone with log access can see credentials in plain text
• Credentials can leak via referer headers when navigating
• Easy capture during network monitoring

What should happen instead:

• Use POST requests with data in the body
• Always enforce HTTPS
• Never log sensitive fields (even on the server side)

2) Authentication tokens exposed in URLs

Very similar problem, slightly different flavor. Instead of passwords, apps expose session tokens or API keys like:

/getUserData?TokenAuthenticate=abc123xyz

That token is basically the user’s identity. If someone gets it, they don’t need the password anymore.

Why it’s dangerous:

• Tokens in URLs get cached, logged, and shared
• A copied link = instant account access
• No need to crack anything — just reuse

Real-world scenario: You send a link to a colleague. The token is in it. They open it… now they’re logged in as you without knowing your password.

Better approach:

• Send tokens in headers (Authorization: Bearer <token>)
• Keep tokens short-lived
• Rotate and invalidate properly

3) No proper input validation (hello injection attacks)

5

If an app trusts user input blindly, it’s basically inviting trouble.

Example login bypass:

Username: admin
Password: ' OR 1=1 -

If the backend is sloppy, that turns into:

SELECT * FROM users WHERE username='admin' AND password='' OR 1=1

…and suddenly, login successful.

Other variants:

• XSS (injecting scripts into pages)
• Command injection
• File path traversal

Why it happens:

• Developers assume “users will behave”
• No sanitization or parameterization

Fix:

• Use prepared statements (no string-built queries)
• Validate + sanitize all inputs
• Treat everything from the user as hostile by default

4) Weak or broken authentication logic

Sometimes the issue isn’t encryption — it’s logic.

Example:

• Step 1: Enter phone number
• Step 2: Receive OTP
• Step 3: Verify OTP

But the backend API lets you skip step 2 entirely and directly hit:

/verifyUser?user=123&status=verified

No OTP needed. Game over.

Common cases:

• OTP not actually validated
• No rate limiting → brute force attacks
• Password reset links that never expire

Impact:

• Account takeover without credentials
• Automated attacks scale easily

Fix:

• Enforce server-side validation (never trust frontend)
• Add rate limiting and lockouts
• Use proper session handling and expiry

5) Storing sensitive data insecurely

If attackers get access to storage and everything is readable, it’s already over.

Examples:

• Passwords stored as plain text in database
• Tokens stored in mobile app local storage without encryption
• API keys hardcoded in the app

Why this is bad:

• One breach = full user compromise
• Users often reuse passwords elsewhere
• Mobile apps can be reverse engineered

Correct approach:

• Hash passwords using strong algorithms (bcrypt, Argon2)
• Encrypt sensitive local data
• Avoid hardcoding secrets in apps

6) Overexposed APIs (too much data, too easy)

6

APIs sometimes return way more than they should.

Example:

GET /api/user/123

Response:

{
  "name": "Rahul",
  "email": "rahul@email.com",
  "password": "hashed_password_here",
  "internal_role": "admin"
}

Even if the password is hashed, why send it at all?

Or worse:

/api/user/124
/api/user/125

…and you can just enumerate users.

Issues here:

• Excessive data exposure
• IDOR (Insecure Direct Object Reference)
• No proper authorization checks

Fix:

• Return only what’s needed
• Enforce authorization on every request
• Use indirect references (UUIDs, not predictable IDs)

Wrap-up (what ties all of this together)

Most of these aren’t “advanced hacker tricks.” They’re basic design mistakes:

• Trusting the client too much
• Not thinking about how data flows
• Convenience over security

If you’re testing apps, these are low-hanging fruit. If you’re building apps, these are things you fix early — otherwise someone else will “find” them for you.