PHP security rules
The 18 checks behind the PHP Safe scanner. Each one comes with a vulnerable example, the secure fix and its CWE and OWASP references.
Injection 8
SQL built with variables (SQL injection)
Joining input into SQL lets an attacker rewrite the query itself and read, change or delete anything in the database. Prepared statements send the query and the values separately, so input can never become SQL.
Learn more βShell command execution
Input passed to the shell can append extra commands with characters such as ; or |, handing the attacker control of the server. Validate the value strictly and quote every argument.
Learn more βCode execution with eval()
eval() runs whatever PHP it receives. If any part of that string comes from a request, an attacker can run their own code on your server.
Learn more βpreg_replace with the /e modifier
The /e modifier evaluated the replacement as PHP code. It was removed in PHP 7, so code that still uses it is dangerous on old servers and broken on new ones.
Learn more βFile inclusion from user input
Building include paths from input lets attackers load system files, uploaded images containing PHP or remote code. It is one of the fastest routes to a full server takeover.
Learn more βInclude path built from a variable
A variable include path is only safe if the variable can never hold user input. It is worth confirming, because the value often comes from a request further up the code.
Learn more βunserialize() on untrusted data
unserialize() can create any object, and attackers chain existing classes (gadgets) to delete files or run code. JSON only ever produces plain data.
Learn more βextract() on request data
extract() turns every request field into a variable, so an attacker can overwrite variables such as $is_admin just by adding a field to the form.
Learn more βOutput and redirects 2
Unescaped user input in output (XSS)
Printing raw input lets an attacker inject scripts that run in your visitors' browsers, stealing sessions or changing what they see. Escaping turns special characters into harmless text.
Learn more βOpen redirect
Attackers send links on your trusted domain that bounce visitors straight to phishing pages.
Learn more βFiles and uploads 2
File access from user input
Sequences such as ../ let a request escape the intended folder and read configuration files, keys or source code.
Learn more βUpload saved with the original file name
Keeping the original file name lets an attacker upload shell.php into a public folder and run it. A random name, a real type check and storage outside the web root stop this.
Learn more βCryptography and transport 3
md5() or sha1() used
md5 and sha1 are fast, so leaked password hashes can be cracked at billions of guesses per second. password_hash() is deliberately slow and salted.
Learn more βPredictable random number
rand(), mt_rand() and uniqid() are predictable. Tokens for password resets, sessions or CSRF must come from a cryptographically secure source.
Learn more βSSL certificate checks turned off
Without certificate checks, anyone on the network path can impersonate the API you call and read or change the data, including your API keys.
Learn more βConfiguration and exposure 3
phpinfo() exposes server details
phpinfo() reveals the PHP version, file paths, loaded modules and environment variables: a map attackers use to choose their exploit.
Learn more βdisplay_errors turned on in code
Error messages shown to visitors expose file paths, SQL queries and sometimes credentials.
Learn more βDebug output of request data
Dumping request data can print passwords, tokens and internal structure to anyone who triggers the page.
Learn more β