PHP Website Security Basics: SQL Injection, XSS and Other Common Risks

Custom PHP websites are fast and flexible — but their security depends entirely on how they're written. Most hacks we see on small business sites come from a few predictable mistakes. This guide explains them in plain language for business owners, with the key fixes developers should apply.

1. SQL injection

What it is: an attacker types database commands into a form field or URL, and the website runs them — exposing or deleting data.

Fix: use prepared statements (parameterised queries) for every database query that includes user input. Never build SQL by joining strings with values from $_GET, $_POST or cookies.

$stmt = $conn->prepare("SELECT * FROM posts WHERE slug = ?");
$stmt->bind_param("s", $slug);
$stmt->execute();

2. Cross-site scripting (XSS)

What it is: an attacker injects JavaScript into a page (via a form, URL or comment) that runs in other visitors' browsers.

Fix: escape all output with htmlspecialchars() (or equivalent) when displaying user-provided data, including in admin panels. Validate inputs, and use a Content Security Policy where practical.

3. Weak or exposed admin panels

• Use strong, unique passwords — preferably hashed and stored securely, not hard-coded.
• Limit login attempts; consider two-factor authentication.
• Protect every admin page with a session check, not just the login page.
• Use a non-obvious admin path and, where possible, IP restrictions.

4. Leftover debug and test files

Files like test.php, debug.php, phpinfo pages, database dumps and old backups in public folders give attackers information or direct access. Remove them from the live server and block sensitive file types in .htaccess.

5. File uploads

• Allow only specific file types; check the actual content, not just the extension.
• Rename uploaded files and store them outside executable paths, or block PHP execution in upload folders.
• Limit file size.

6. Secrets in code

API keys, SMTP passwords and payment keys shouldn't be committed to shared code or left in public files. Store them in configuration files outside the web root or environment variables, and rotate any key that may have leaked.

7. Sessions and cookies

Use secure, HttpOnly cookies over HTTPS, regenerate session IDs after login, and set session timeouts for admin areas.

8. CSRF

Admin forms that change data should include CSRF tokens so attackers can't trick a logged-in admin's browser into submitting actions.

9. Keep the platform updated

Use a supported PHP version, keep libraries (like PHPMailer) updated, and remove unused code.

Frequently Asked Questions

Is custom PHP less secure than WordPress?

Not inherently. Well-written custom code has a small attack surface; poorly written code is risky. WordPress has its own risks through plugins.

How do I know if my site is vulnerable?

A code review and security scan by an experienced developer is the most reliable way.

What should I do if an API key was exposed?

Revoke it immediately in the provider's dashboard and create a new one.

Get a security review

Joboo Web reviews and secures PHP websites. Read our hacked website recovery guide or contact us.