PHP Security

Vulnerabilities arising during PHP application development and the coding, configuration, and operational security principles used to defend against them

PHP Security

Overview

PHP security refers to a set of practices for preventing security vulnerabilities that can arise in web applications written in PHP, and for minimizing the attack surface through secure coding, server configuration, and operational management. PHP is a language that accounts for a significant portion of web servers worldwide, and historically there have been many cases of traditional vulnerabilities such as SQL injection, XSS, and file inclusion. However, with the PHP 7 and 8 generations, language-level safeguards have been strengthened, and safe development practices are taking hold through the spread of frameworks and static analysis tools.

Key Content

1. Representative Vulnerability Types

  • SQL Injection: Occurs when user input is concatenated directly into a query. It can be fundamentally blocked by using prepared statements and binding in PDO or mysqli.
  • Cross-Site Scripting (XSS): The basic approach is to escape output with htmlspecialchars($str, ENT_QUOTES, 'UTF-8'). Adding a Content Security Policy (CSP) header provides defense in depth.
  • CSRF (Cross-Site Request Forgery): State-changing requests must issue and verify session-based CSRF tokens.
  • File Inclusion and Path Traversal: Do not use user input directly in include, require, or file upload paths; validate it using a whitelist approach.
  • Remote Code Execution (RCE): Typical vectors include eval(), assert(), the /e modifier of preg_replace(), and misuse of unserialize().
  • Session Hijacking: Defend by regenerating the session ID (session_regenerate_id(true)) and setting the HttpOnly, Secure, and SameSite cookie attributes.

2. Secure Coding Principles

1. Separate Input Validation and Output Encoding: Clearly define trust boundaries, validate all external input, and encode all output according to context.

2. Principle of Least Privilege: Minimize database account, file system, and process privileges.

3. Separate Secret Information: Do not hard-code DB credentials or API keys in code; manage them with environment variables or a secret manager.

4. Control Error Exposure: In production environments, set display_errors=Off and log_errors=On, and record detailed errors only in logs.

5. Secure Password Storage: Use bcrypt/Argon2 with password_hash() and password_verify(). MD5 and SHA1 are absolutely prohibited.

3. Server and Runtime Configuration

  • In php.ini, set expose_php=Off, allow_url_include=Off, and allow_url_fopen=Off (restricted if necessary), specify open_basedir, and block dangerous functions with disable_functions.
  • For file uploads, validate extension, MIME type, and size, and store files outside the web root or in a non-executable directory.
  • Force HTTPS and apply the Strict-Transport-Security header.
  • Regularly check Composer dependencies with composer audit, and immediately update vulnerable packages.

4. Tools and Frameworks

Modern frameworks such as Laravel and Symfony provide query binding in their ORMs, automatic escaping in Blade/Twig templates, and CSRF middleware by default. Widely used static analysis tools include PHPStan, Psalm, and PHP_CodeSniffer (including security rules), while OWASP ZAP and Burp Suite are widely used for dynamic diagnosis. Integrating SAST/DAST into CI pipelines has become standard practice.

Latest Trends

As of 2024-2025, the major changes in the PHP security ecosystem are as follows. First, migration to PHP 8.1 or higher is effectively nearing completion, and the use of end-of-life (EOL) versions has emerged as a major risk factor. PHP 8.4 (released in November 2024) introduced property hooks and asymmetric visibility, and the security community is documenting safe usage patterns for the new syntax. Second, responding to supply chain attacks has emerged as a key agenda. As cases of typosquatting and malicious packages have been reported in the Packagist and Composer ecosystem, pinning composer.lock, hash verification, and the adoption of SBOMs (Software Bills of Materials) are recommended. Third, the spread of AI-based code generation tools has increased the risk of insecure patterns being introduced into automatically generated PHP code, and in response, the importance of AI code review and automated static analysis is being emphasized. Fourth, in line with the latest revision trend of the OWASP Top 10, vulnerable component management and authentication/session design failures are being re-highlighted as top-priority risks. Finally, as zero trust architecture and granular privilege management are applied to PHP-based backends as well, design that moves away from the traditional perimeter-defense-centric mindset and verifies least privilege even inside the application is spreading.

Related Topics

  • [[SQL Injection]]
  • [[Cross-Site Scripting]]
  • [[OWASP Top 10]]
  • [[PHP]]
  • [[Web Application Firewall]]