register_globals Era & Why It Was Dangerous
debt(d5/e7/b5/t7)
Closest to 'specialist tool catches it' (d5). The detection_hints list phpcs (PHP CodeSniffer) as the tool, which is a specialist static analysis tool rather than a default linter or compiler. It can detect register_globals usage patterns in code, but only if explicitly configured and run — not caught at compile time or by default tooling.
Closest to 'cross-cutting refactor across the codebase' (e7). The quick_fix notes this requires auditing ALL variables for explicit superglobal assignment across the entire codebase — legacy code written under register_globals assumptions has implicit variable creation baked into every function and file. There is no single-line patch; it requires systematically hunting down every variable that may have been auto-populated from user input, touching many files throughout the application.
Closest to 'persistent productivity tax' (b5). The applies_to scope is web contexts for PHP 3.0–5.3 era code. Legacy codebases written under register_globals assumptions impose an ongoing audit burden on maintainers who inherit them — every variable must be questioned, and the assumption that variables are safe persists as a shadow over the codebase. However, it is not load-bearing across modern PHP systems since the feature was removed in 5.4.
Closest to 'serious trap' (t7). The misconception field states explicitly that register_globals was considered a 'minor issue' when in fact it made every PHP app trivially vulnerable to authentication bypass. A competent developer unfamiliar with the era might assume the feature was merely inconvenient or deprecated for cleanliness reasons, not that it was catastrophically dangerous and responsible for thousands of exploits. This contradicts intuitions formed in modern frameworks where variable scoping is safe by default.
TL;DR
Explanation
register_globals was on by default in PHP 3 and PHP 4.0-4.1. PHP 4.2 (2002) turned it off by default — a turning point for PHP security. Before that: every GET/POST/COOKIE param became a global. Millions of PHP apps had auth bypass vulnerabilities. The history: PHP was designed for small scripts, security was an afterthought. The shift to off-by-default caused enormous backlash (many apps broke) but was essential. register_globals was deprecated in PHP 5.3 and removed in PHP 5.4. It's the single biggest security mistake in PHP's history.
Common Misconception
Why It Matters
Common Mistakes
- Not auditing inherited legacy code for register_globals assumptions.
- Assuming all PHP before 5.4 is safe if register_globals was off — other security issues remained.
Code Examples
// PHP with register_globals=On:
// URL: ?admin=1 sets $admin=1
if ($admin) {
echo 'Welcome, administrator'; // Auth bypass!
}
// Modern: always explicit:
$isAdmin = (bool)($_SESSION['is_admin'] ?? false);
if ($isAdmin) {
echo 'Welcome, administrator';
}