Common PHP Security Mistakes That Get Nigerian Websites Hacked

Custom PHP applications get compromised through a small, repeating set of mistakes. If you're running custom PHP (not just WordPress) for your business, this is the list to check.

1. SQL injection via unescaped input

Building SQL queries by directly concatenating user input is still, in 2026, one of the most common vulnerabilities I find in custom Nigerian business systems. The fix: always use prepared statements (PDO or MySQLi with bound parameters), never string-concatenate variables into a query. This is not optional or a "nice to have" — it's the baseline requirement for any code touching a database with user input.

2. Exposed .env files and credentials

Database passwords, API keys, and payment gateway secrets sitting in a .env file that's accidentally web-accessible (not blocked by .htaccess or outside the public web root) is a disturbingly common find. Anyone who guesses or finds the URL gets your full credential set. The fix: keep .env and any config files with secrets outside the publicly served directory, or explicitly block access to them in your web server config.

3. Weak or missing session security

Sessions without proper expiration, session IDs passed in URLs (exposing them in browser history and server logs), or no regeneration of the session ID after login all weaken authentication. The fix: use session_regenerate_id() after login, set secure session cookie flags, and enforce reasonable session timeouts.

4. Trusting client-side validation alone

JavaScript form validation is a UX nicety, not a security control — anyone can bypass it with browser dev tools or a direct API call. The fix: validate and sanitize every input again on the server, regardless of what client-side checks already ran.

5. File upload vulnerabilities

Allowing file uploads without checking the actual file type (not just the extension, which is trivially spoofed) can let an attacker upload a PHP file disguised as an image and execute it. The fix: validate file content type properly, store uploads outside the web-executable directory where possible, and never allow uploaded files to execute as PHP.

6. Outdated PHP versions with known vulnerabilities

Running PHP 7.4 or earlier (end of life, no security patches) because "it still works" leaves known, publicly documented vulnerabilities unpatched. The fix: stay on a currently supported PHP version (8.1+ as of 2026), and actually test the upgrade rather than avoiding it indefinitely out of fear of breaking something.

7. Verbose error messages in production

Leaving display_errors on in production shows attackers your file paths, database structure, and stack traces whenever something goes wrong — a reconnaissance gift. The fix: disable display_errors in production, log errors server-side instead, and show generic error pages to visitors.