The same handful of problems
Despite the variety of attacks discussed in security literature, the PHP applications we are asked to investigate have been compromised through a small and consistent set of causes.
Getting five things right eliminates the overwhelming majority of practical risk.
Database access
- Prepared statements with bound parameters, always — never string concatenation
- That includes ORDER BY and LIMIT clauses, which are commonly overlooked
- Least-privilege database credentials, not a superuser
- No database errors displayed to users, ever
Injection through a search box or a sort parameter remains the most common way a PHP application is compromised, and prepared statements make it impossible.
Output escaping
Anything that came from a user and is rendered into a page must be escaped for its context. HTML, attributes, JavaScript and URLs each need different treatment.
Modern template engines escape by default, which is one of the strongest arguments for using one rather than writing raw PHP templates.
Authentication and sessions
- Use the framework's authentication rather than writing your own
- Password hashing with the language's current recommended function
- Session identifiers regenerated on privilege change
- Secure and HttpOnly flags on session cookies
- Rate limiting on login attempts
File uploads and dependencies
| Risk | Control |
|---|---|
| Uploaded files executed | Store outside the web root, always |
| Type spoofing | Validate content, not the extension |
| Path traversal | Never use user input in a file path |
| Vulnerable dependencies | Automated auditing on every build |
| Outdated PHP version | Stay on a supported release |
File uploads stored inside the web root is the second most common compromise route we find, after injection.