Superglobals ($_GET, $_POST, $_SERVER…)
Also Known As
PHP superglobals
$_GET $_POST $_REQUEST
$_SERVER $_SESSION
TL;DR
PHP's built-in global arrays that provide access to request data, environment, and server variables — all potentially attacker-controlled.
Explanation
PHP superglobals ($_GET, $_POST, $_COOKIE, $_FILES, $_SERVER, $_SESSION, $_ENV, $_REQUEST) are accessible in any scope without declaration. Critically, all data from HTTP requests ($_GET, $_POST, $_COOKIE, $_REQUEST, and many $_SERVER keys) is attacker-controlled and must be validated and sanitised before use. $_SERVER['HTTP_HOST'], $_SERVER['HTTP_REFERER'], and $_SERVER['HTTP_X_FORWARDED_FOR'] are trivially spoofed. Never trust superglobal data without validation, and avoid $_REQUEST which merges GET, POST, and cookies.
Common Misconception
✗ $_REQUEST is a convenient and safe alternative to $_GET and $_POST. $_REQUEST merges GET, POST, and COOKIE data — the precedence order is configurable and can be manipulated to override expected input sources. Always read from the explicit $_GET or $_POST superglobal.
Why It Matters
PHP superglobals ($_GET, $_POST, $_SERVER, $_SESSION) are accessible everywhere without declaration — accessing them directly throughout the codebase creates hidden input coupling and makes testing harder.
Common Mistakes
- Reading $_GET/$_POST directly in domain or service classes — those layers should receive already-validated data.
- Trusting $_SERVER['HTTP_HOST'] for security decisions — it is user-controlled.
- Modifying $_SESSION directly in many places instead of through a session service — hard to trace and test.
- Not filtering and validating superglobal values at the application boundary before passing them inward.
Avoid When
- Never use $_REQUEST — it merges GET, POST, and COOKIE, making the input source ambiguous.
- Do not use extract($_GET) or extract($_POST) — it overwrites arbitrary variables with user-controlled values.
When To Use
- Access $_GET, $_POST, $_SERVER through a request abstraction layer rather than directly — makes testing and sanitisation consistent.
- Always validate and sanitise superglobal values before use — they contain raw user input.
Code Examples
✗ Vulnerable
// Superglobals accessed deep in domain logic:
class OrderService {
public function create(): Order {
$userId = $_SESSION['user_id']; // Coupled to HTTP context
$items = $_POST['items']; // Should be injected, not read directly
}
}
✓ Fixed
// PHP superglobals — always available, all scopes
// \$_GET — URL query params
// \$_POST — HTTP POST body (form data)
// \$_COOKIE — HTTP cookies
// \$_FILES — uploaded file metadata
// \$_SERVER — server and request info
// \$_SESSION — session data (after session_start())
// \$_ENV — environment variables
// \$_REQUEST — merged GET+POST+COOKIE (avoid — ambiguous)
// \$GLOBALS — all global variables
// Safe access pattern:
\$page = max(1, (int) (\$_GET['page'] ?? 1));
\$email = filter_var(\$_POST['email'] ?? '', FILTER_VALIDATE_EMAIL) ?: '';
// JSON API body:
\$body = json_decode(file_get_contents('php://input'), true) ?? [];
Tags
🤝 Adopt this term
£79/year · your link shown here
Added
15 Mar 2026
Edited
31 Mar 2026
Views
23
🤖 AI Guestbook educational data only
|
|
Last 30 days
Agents 0
No pings yet today
No pings yesterday
Amazonbot 8
Perplexity 2
Unknown AI 2
Google 2
Ahrefs 1
ChatGPT 1
Also referenced
How they use it
crawler 15
crawler_json 1
Related categories
⚡
DEV INTEL
Tools & Severity
🟠 High
⚙ Fix effort: Medium
⚡ Quick Fix
Never use superglobal values directly in business logic — filter and validate at the controller boundary using filter_input() or a validation library, then pass clean values to services
📦 Applies To
PHP 5.0+
web
cli
queue-worker
🔗 Prerequisites
🔍 Detection Hints
\$_GET or \$_POST used directly in SQL query or file path; \$_SERVER['HTTP_HOST'] used without validation; superglobals in domain service classes
Auto-detectable:
✓ Yes
phpstan
semgrep
deptrac
⚠ Related Problems
🤖 AI Agent
Confidence: Medium
False Positives: High
✗ Manual fix
Fix: High
Context: File
Tests: Update