How to Secure a PHP Website in 2026: A Practical Hardening Checklist

The October 2026 emergency PHP release is a reminder that the security of a PHP website depends on more than the code you wrote. It depends on the PHP version, the server configuration, the plugins and libraries you installed years ago, and how quickly you can apply an update when it matters. This checklist covers the layers we harden on every PHP project, in order of impact.

1. Run a Supported PHP Version

This is the single most important item. Supported PHP versions receive fixes for new vulnerabilities; end-of-life versions do not. As of October 2026, PHP 8.1 and older are end-of-life, PHP 8.2 loses security support on December 31, 2026, and PHP 8.3, 8.4 and 8.5 are supported. If your site runs anything older than 8.3, plan an upgrade now.

2. Keep Everything Else Updated

• CMS core (WordPress, Magento, Drupal, Joomla) and framework (Laravel, Symfony, CodeIgniter) on a supported release
• Plugins, themes and extensions updated — and abandoned ones removed or replaced, since they will never be patched
• Composer dependencies checked with composer audit, which reports packages with known security advisories
• The operating system, web server and database server patched regularly

3. Harden php.ini

• display_errors = Off in production, with log_errors = On, so error messages never reveal file paths or queries to visitors
• expose_php = Off to stop advertising your PHP version in HTTP headers
• allow_url_include = Off so remote files can never be included as code
• disable_functions for dangerous functions your application does not use, such as exec, shell_exec, system and passthru
• open_basedir to restrict which directories PHP can read and write
• Sensible upload_max_filesize, post_max_size, memory_limit and max_execution_time values

4. Secure Sessions and Logins

• session.cookie_secure, session.cookie_httponly and session.cookie_samesite set, and session.use_strict_mode enabled
• Regenerate the session ID after login with session_regenerate_id(true)
• Hash passwords with password_hash() and verify with password_verify() — never MD5, SHA1 or home-made hashing
• Rate-limit login attempts, and offer two-factor authentication for admin accounts

5. Stop SQL Injection and XSS in the Code

Use prepared statements with PDO or mysqli for every query that includes user input — or the query builder or ORM of your framework. Never build SQL by concatenating $_GET or $_POST values. For output, escape everything that came from users with htmlspecialchars($value, ENT_QUOTES, 'UTF-8') or your template engine's auto-escaping (Blade and Twig escape by default). Validate input on the server even when the browser already validates it.

6. Lock Down File Uploads

• Check the real file type on the server (finfo), not just the extension or the browser-supplied MIME type
• Rename uploaded files to random names and store them outside the web root, or in object storage such as S3
• Disable PHP execution in any upload directory at the web server level
• Limit file size and the allowed types to exactly what the feature needs

7. Protect Forms and Requests

• CSRF tokens on every form that changes data — built into Laravel and Symfony, and available as nonces in WordPress
• CAPTCHA or bot protection on public forms such as contact, registration and password reset
• Rate limiting on login, search and API endpoints

8. Add Security Headers and HTTPS Everywhere

• HTTPS on every page, with HTTP redirected and Strict-Transport-Security (HSTS) enabled
• Content-Security-Policy to limit where scripts can load from — very effective against injected payment skimmers
• X-Content-Type-Options: nosniff, Referrer-Policy and X-Frame-Options or frame-ancestors

9. Server, Access and Permissions

• Run PHP-FPM as a dedicated low-privilege user, never as root
• Files owned by a deploy user and not writable by the web server, except specific cache and upload folders
• Keep .env, config files, .git and backups out of the web root
• SSH with keys only, admin panels restricted by IP or VPN where possible, and a web application firewall (WAF) in front of the site

10. Backups, Monitoring and a Response Plan

Automated daily backups stored off the server — and tested by actually restoring them. Uptime monitoring and alerts for error spikes. File integrity monitoring to detect changed PHP files. And a written plan for what to do when a critical vulnerability like CVE-2026-109618 is announced: who applies the update, how quickly, and how it is verified. Sites that had this plan in place were patched within hours of the October 2026 release.

Want a Professional Security Review?

Frequent Solutions audits and hardens PHP websites and applications — WordPress, WooCommerce, Magento, Laravel, CodeIgniter and custom PHP. We upgrade unsupported PHP versions, fix insecure code, and set up the monitoring and update process that keeps your site safe. Request a free audit to find out where your site stands.