8 Things Devs Did Wrong That Got Their Apps Hacked

Modern web applications are built fast, integrated with everything, and deployed to the cloud in minutes. That’s great for business agility—but it might also be introducing some great risks to the business! In dozens of real-world penetration tests, our team has seen the same developer missteps that led directly to breaches, data leaks, and ransomware footholds.

Here are eight mistakes that real-world dev teams made—and how to avoid them.

1. Hard-coding credentials into source code

From AWS keys to database passwords, credentials left in GitHub or GitLab repos remain one of the top ways attackers gain initial access. Once that API key is in the repo history, it’s there forever.

Fix: Use secret-management tools (e.g., AWS Secrets Manager, HashiCorp Vault, Doppler) and environment variables—never commit keys to code. Scan repos regularly with tools like TruffleHog or GitLeaks.

2. Relying on “security by obscurity”

We’ve tested apps where developers renamed the admin panel to /hidden-admin/ or thought obscured API endpoints were “good enough.” Attackers can enumerate every endpoint and directory in seconds.

Fix: Properly authenticate and authorize every sensitive function. Assume all routes and endpoints are discoverable.

3. Failing to validate user input

Injection vulnerabilities (SQLi, NoSQLi, command injection) are still alive and well. We’ve compromised production databases through simple form fields that weren’t sanitized.

Fix: Use parameterized queries, input validation frameworks, and sanitize all data before execution or output. Never trust the client side.

4. Misconfigured access controls

We often find broken role logic: “user” accounts can hit “admin” endpoints because the front-end hides the button but doesn’t enforce the rule server-side. Attackers don’t need buttons—they have Burp Suite or other tools that inspect and modify network traffic on the fly.

Fix: Enforce authorization checks in backend code, not the UI. Implement role-based access control and test it.

5. Ignoring dependencies and outdated libraries

An app is only as secure as its weakest dependency. We’ve exploited decade-old jQuery versions and vulnerable npm packages that were never patched.

Fix: Run dependency checks and patch management routinely (e.g., npm audit, pip-audit, Snyk, Dependabot). Maintain a software bill of materials (SBOM) so you know what you’re actually running.

6. Weak session management

Insecure cookie flags, long-lived JWTs, and missing CSRF protection allow attackers to hijack sessions easily. One app we tested used the same token for 24 hours after logout—instant replay attacks.

Fix: Shorten token lifetimes, set HttpOnly and Secure flags, invalidate sessions on logout, and implement CSRF tokens.

7. IDOR (Insecure Direct Object Reference) flaws

Developers frequently expose internal object identifiers directly in URLs or API parameters (for example /api/user/12345/invoices or GET /files?id=9876). If authorization checks are missing or rely solely on input obscurity, an authenticated user can simply change that id value and access another user’s data—often without any trace. We’ve pulled entire customer datasets by incrementing numeric IDs or swapping GUIDs we found in API calls.

Fix: Never rely on client-supplied object identifiers for authorization. Always:

  • Enforce server-side authorization checks that confirm the requesting user has the right to access the specific object.

  • Use indirect references or per-user object lookup (e.g., map user-visible-id → internal-id on the server).

  • Implement strong multi-tenant separation checks and log access attempts for anomaly detection.

8. Skipping security testing altogether

This one’s the killer. Some dev teams never run a vulnerability scan or pen test until after a breach. By then, it’s damage control.

Fix: Integrate testing throughout your lifecycle—static analysis (SAST), dynamic testing (DAST), dependency scanning, and regular third-party penetration testing. Build security into your CI/CD pipeline, not after deployment.

Final Thoughts

Every one of these mistakes was preventable. They weren’t zero-days or nation-state attacks—just avoidable errors that opened the door for opportunistic hackers.

At Mile High Cyber, our penetration testing and vulnerability management programs help development teams catch these problems before attackers do. We combine human-led testing with automated coverage to give you clear, actionable findings that strengthen your app security—without slowing down your dev cycle.

Ready to see what attackers would find in your app?

Schedule a consultation with Mile High Cyber

Next
Next

The Painful Cost of Skipping Regular Security Testing