Why This Matters in 2026
The attack surface for web applications has expanded significantly. AI-assisted attack tools have made it trivially easy for attackers to probe for common vulnerabilities at scale. The cost of a breach has reached an average of $4.88M globally, and mid-sized companies in the GCC are now primary targets — not just enterprises.
The encouraging news: most of the vulnerabilities we find are fixable within hours. The problem is that development teams don't know to look for them.
The Checklist
1. Missing Security Headers
This is the single most common finding. Security headers are free, take 5 minutes to configure, and prevent entire categories of attacks. Check your site at securityheaders.com — if you're not getting an A or A+ rating, you're exposed.
The minimum required headers are: Content-Security-Policy, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy, and Strict-Transport-Security (HSTS).
2. SQL Injection via Raw Queries
Still appearing in 2026. Developers often use raw queries for complex filtering and forget to parameterize. Any user input that touches a database query must go through prepared statements or a query builder — no exceptions.
3. Predictable Session IDs
Weak session tokens or session IDs that encode user information are exploitable. Your session IDs should be cryptographically random and contain no decodable user data. PHP's default session handling, if misconfigured, still generates predictable IDs in some configurations.
4. Missing CSRF Protection on State-Changing Endpoints
CSRF tokens are required on every POST, PUT, PATCH, and DELETE endpoint. We regularly find API endpoints and AJAX routes that skip the CSRF middleware because developers assume "no browser will send this." Attackers know otherwise.
5. Exposed .env and Configuration Files
Still disturbingly common. A misconfigured Nginx or Apache server will serve .env, .git/config, or composer.json to anyone who requests it. Your .env file contains database credentials, API keys, and encryption keys. Add explicit deny rules for these files and verify with curl https://yourdomain.com/.env.
6. Insecure Direct Object References (IDOR)
The most impactful vulnerability we find. An IDOR occurs when a user can access another user's resource simply by changing an ID in the URL or request body — e.g., /invoices/1234 returns your data, but /invoices/1235 returns someone else's. Every data access must verify the authenticated user owns the requested resource.
7. Unrestricted File Uploads
Accepting file uploads without validating type, size, and content allows attackers to upload PHP shells or malicious scripts. Never trust the Content-Type header alone — inspect the actual file magic bytes. Store uploaded files outside the webroot or in a separate storage service.
8. Verbose Error Messages in Production
Error messages that expose stack traces, database queries, file paths, or framework versions give attackers a map of your application. APP_DEBUG=true in production is a critical issue. Error messages shown to users should be generic; details should go to your logging system only.
9. Missing Rate Limiting
Login endpoints, password reset, OTP verification, and API endpoints without rate limiting are vulnerable to brute force and enumeration attacks. Implement IP-based rate limiting at both the application layer and Cloudflare level. For login endpoints, 5 attempts per minute per IP is a reasonable starting point.
10. Weak Password Policies
Many applications still accept 6-character passwords and don't check against known breach databases. Minimum 10 characters, complexity requirements, and integration with the HaveIBeenPwned API to block known compromised passwords reduces account takeover risk significantly.
11. No Subresource Integrity (SRI) for External Scripts
If you load JavaScript or CSS from a CDN, a compromised CDN can inject malicious code into your site. Add integrity and crossorigin attributes to all external resource tags. This is particularly critical for payment or authentication-related pages.
12. Excessive User Permissions (Over-Privileged Accounts)
Application database users that can DROP TABLE or CREATE USER are a disaster waiting to happen. The database user your application uses should only have SELECT, INSERT, UPDATE, DELETE privileges on the specific tables it needs — nothing more.
13. Unencrypted Sensitive Data at Rest
Personally identifiable information, financial data, and authentication credentials stored as plain text in your database create catastrophic exposure if the database is ever accessed. Encrypt sensitive fields at the application level, not just at the database level.
14. Missing HTTP/HTTPS Redirect
Applications that serve content over both HTTP and HTTPS allow attackers to strip SSL (SSL stripping attacks). Force HTTPS everywhere, set an HSTS header with a long max-age, and consider submitting to the HSTS preload list.
15. Outdated Dependencies with Known CVEs
Run composer audit (PHP) or npm audit (Node.js) on every production application right now. Known CVEs in third-party packages are actively exploited. Automate dependency scanning in your CI/CD pipeline — GitHub Dependabot is free.
16. No Web Application Firewall (WAF)
Cloudflare's free plan includes a basic WAF. Their paid plans include managed rulesets that block OWASP Top 10 attacks at the edge, before they reach your server. For any production application handling user data or payments, a WAF is non-negotiable.
17. Lack of Monitoring and Alerting
A security posture without monitoring is just hope. You need to know when someone is brute-forcing your login, when your error rate spikes, or when an unusual data access pattern occurs. Set up application-level logging, configure alerts, and review logs weekly at minimum.
Running This Checklist on Your Application
Go through this list with your current production application. For each item, either confirm it's implemented correctly or add it to your next sprint. The items in this list are not theoretical — every single one represents a real vulnerability we found in a real production system in the last 12 months.
If you'd like us to run a formal audit against your application, we conduct grey-box penetration tests that cover all 17 items above plus full OWASP Top 10 testing. Most audits are completed within 5–7 business days.
Ready for a Professional Audit?
We'll test your application against all 17 items on this list plus the full OWASP Top 10. You'll receive a detailed report within 5 business days.