Superglobals and Request Data
PHP automatically populates a set of predefined arrays called superglobals at the start of every request, and unlike ordinary variables they are available inside every scope — global code, functions, and methods — without needing a global keyword or being passed as a parameter. These arrays are how PHP hands your script the raw ingredients of an HTTP request: query string parameters, form-submitted fields, uploaded files, cookies, and server/environment metadata. Understanding which superglobal holds which piece of data, and treating all of it as untrusted user input, is foundational to writing correct and secure PHP web applications.
Cricket analogy: Superglobals are like the umpire's pre-filled scorecard handed out automatically at the start of every match, available to every official (function, method, global code) without anyone having to physically pass it around; treating every field on that card as unverified until checked is essential to fair scoring.
$_GET, $_POST, and $_REQUEST
$_GET contains key-value pairs parsed from the URL's query string (everything after the ? in /search?q=php&page=2), while $_POST contains form fields submitted with a POST request whose content type is application/x-www-form-urlencoded or multipart/form-data. $_REQUEST merges $_GET, $_POST, and $_COOKIE according to the php.ini request_order setting, but relying on it is discouraged in modern code because it obscures exactly where a value came from, which matters for both correctness and security — a value an attacker controls via the query string should not silently satisfy a check meant only for a submitted form field.
Cricket analogy: $_GET from /scorecard?match=42&over=15 mirrors query-string parameters like a match ID, while $_POST holds a submitted post-match report form; relying on $_REQUEST is like an announcer not knowing whether a stat came from the official form or a shouted guess from the crowd, which matters for trusting a submitted review request.
<?php
declare(strict_types=1);
// GET /search?q=composer&page=2
$query = $_GET['q'] ?? '';
$page = filter_var($_GET['page'] ?? 1, FILTER_VALIDATE_INT, [
'options' => ['default' => 1, 'min_range' => 1],
]);
// POST form submission
if ($_SERVER['REQUEST_METHOD'] === 'POST') {
$email = trim($_POST['email'] ?? '');
if (!filter_var($email, FILTER_VALIDATE_EMAIL)) {
http_response_code(422);
exit('Invalid email address.');
}
}
echo "Searching for '{$query}' on page {$page}\n";
$_SERVER, $_ENV, and $_COOKIE
$_SERVER carries metadata about the request and the server environment — the HTTP method, request URI, headers (surfaced as HTTP_* keys), client IP, and the running script's path. $_ENV exposes environment variables the server process was started with, commonly used to inject configuration like database credentials or API keys outside of version control. $_COOKIE reflects cookies the client sent with the request; note that it only reflects cookies already stored in the browser from a previous response — setting a new cookie via setcookie() does not populate $_COOKIE until the following request.
Cricket analogy: $_SERVER carries request metadata like the HTTP method and client IP the way a stadium's entry log records gate and time; $_ENV exposes environment variables like an API key for a weather-delay service; $_COOKIE only reflects a 'remember my seat' cookie from a previous visit, not one just set this response.
Think of superglobals as a read-only inbox the PHP engine fills in for you before your script even starts running. You never construct $_GET or $_POST yourself — the engine parses the incoming HTTP request and drops the parsed results into these arrays automatically, once per request.
Never trust any superglobal value directly in a query, filesystem path, shell command, or HTML output without validating and escaping it appropriately (parameterized queries for SQL, htmlspecialchars() for HTML). Every superglobal represents data that originated outside your application's control, even $_SERVER fields like HTTP_REFERER or HTTP_USER_AGENT, which a client can set to anything.
$_FILES and $GLOBALS
$_FILES holds metadata about uploaded files from a multipart form — each entry includes the temporary upload path, original filename, MIME type as reported by the client, size, and an error code that must be checked before trusting the upload succeeded. $GLOBALS is a superglobal array giving read/write access to every variable currently defined in the global scope from within any function, though modern style strongly favors explicit parameters and dependency injection over reaching into $GLOBALS, which makes data flow far harder to trace.
Cricket analogy: $_FILES holds metadata about an uploaded scorecard photo (temp path, filename, MIME type, size, error code) that must be checked before trusting the upload; reaching into $GLOBALS from a scoring function to grab the match total directly is like a stray official scribbling on any scoresheet in the pavilion instead of being handed the data properly.
- Superglobals ($_GET, $_POST, $_SERVER, $_COOKIE, $_FILES, $_ENV, $_SESSION, $GLOBALS) are available in every scope without import or the global keyword.
- $_GET reads query string parameters; $_POST reads submitted form body fields; both are string keyed on request.
- $_REQUEST merges $_GET/$_POST/$_COOKIE per php.ini's request_order and is best avoided for precision and security reasons.
- $_SERVER exposes request metadata (method, URI, headers) and environment details about the running script.
- All superglobal data originates outside your application and must be validated/escaped before use in queries, commands, or output.
- $_FILES describes uploaded files and must always be checked for a successful upload error code before further processing.
Practice what you learned
1. Which superglobal contains key-value pairs parsed from a URL's query string?
2. Why is relying on $_REQUEST discouraged in modern PHP code?
3. What does $_SERVER['REQUEST_METHOD'] typically contain?
4. Why must every value read from $_FILES be checked before use?
5. What is the key characteristic that distinguishes superglobals from ordinary PHP variables?
Was this page helpful?
You May Also Like
Form Handling and Validation
Learn a reliable pattern for processing submitted HTML forms in PHP: reading input safely, validating and sanitizing each field, and reporting errors back to the user.
Sessions and Cookies
Learn how PHP maintains state across stateless HTTP requests using cookies for client-side storage and sessions for server-side storage keyed by a session identifier.
PHP Security Basics
Core security practices every PHP developer must apply — input validation, output escaping, safe database access, and secure session handling.
File Uploads in PHP
Learn how PHP handles multipart form uploads through the $_FILES superglobal, including validation, error codes, and safely moving uploaded files on disk.
Related Reading
Related Study Notes in Programming
Browse all study notesApache Spark Study Notes
Programming · 30 topics
ProgrammingApache Flink Study Notes
Programming · 30 topics
ProgrammingHadoop Study Notes
Programming · 30 topics
ProgrammingSnowflake Study Notes
Programming · 30 topics
ProgrammingApache Airflow Study Notes
Programming · 30 topics
Programmingdbt (Data Build Tool) Study Notes
Programming · 30 topics