Web Application Security Checklist: 15 Vulnerabilities Every App Must Handle

Access and authentication

• 1. Other users' data is one ID away: If changing /invoices/1041 to /invoices/1042 shows a stranger's invoice, you have a data breach. Ask: "Does the server check ownership on every request, and is that covered by automated tests?"
• 2. Permissions enforced only in the UI: Hiding the admin button doesn't protect the function behind it. Any user can call it directly. Ask: "Where are roles enforced in the code, and can users change their own role?"
• 3. Cross-site request forgery (CSRF): A malicious site makes a logged-in user's browser submit a form to your app, for example one that changes the account email. Ask: "Do all forms and requests that change data have CSRF protection?"
• 4. Logins that can be guessed or bypassed: Without rate limiting, bots can try passwords leaked from other sites. Ask: "Do we limit login attempts, require two-factor for admins and expire password reset links?"

Configuration, secrets and dependencies

• 5. Misconfigured production: Debug mode left on, default credentials, exposed admin panels or missing HTTPS. Laravel's documentation on debug mode warns that it can expose sensitive configuration values to users in production. Ask: "How do we make sure production is configured differently from development?"
• 6. Secrets in the code: API keys for payments, email or AI left in the code, Git history or browser can run up your bill. Ask: "Where are our keys stored, who can access them, and when were they last rotated?"
• 7. Outdated dependencies: Once a vulnerability in a package is published, anyone can read how to exploit it. Ask: "How do we hear about security updates, and how quickly are they installed?"
• 8. Passwords and data stored badly: Passwords should be hashed with a modern algorithm such as bcrypt or Argon2, never stored in plain text. Sensitive fields and backups should be encrypted. Ask: "How are passwords stored, and are our backups encrypted?"

User input and business logic

• 9. SQL injection: User input goes straight into a database query, so a search box can be used to read or delete your data. Ask: "Do we use parameterized queries everywhere, including hand-written SQL?"
• 10. Cross-site scripting (XSS): Text from one user, such as a comment, runs as code in another user's browser. If it hits an admin, the attacker can take over the account. Ask: "Is all user content escaped on output, and where have we deliberately turned that off?"
• 11. Unrestricted file uploads: Without checks on file type and size, someone can upload code that runs on your server. Private documents should never sit behind a public link. Ask: "Which file types do we accept, and how are private files protected?"
• 12. Business logic that can be gamed: Prices sent from the browser, discount codes that work forever, or no cap on costly actions like SMS or AI calls. Ask: "What happens if someone calls our API directly 1,000 times a minute?"

Integrations, errors and monitoring

• 13. Unverified data and code: A payment webhook needs a verified signature, otherwise anyone can mark an order as paid. The same goes for third-party scripts and deploy access. Ask: "Do we verify signatures on every webhook, and who can push code to production?"
• 14. Errors that leak or fail open: Detailed error messages show attackers how your system works. Worse is code that "fails open", such as approving an order when the payment check times out. Ask: "What does a user see when something breaks, and do we deny by default when a check fails?"
• 15. No logging or alerting: Without logs, you hear about a breach when a customer calls, and you can't tell which data was touched. Ask: "What do we log, how long do we keep it, and who gets alerted?"