Superglobals ($_GET, $_POST, $_SERVER)
This is where PHP becomes a web language. Superglobals are the built-in arrays — $_GET , $_POST , $_SERVER and friends — that carry data from the browser into your script. You'll learn to read them, default them, and most importantly, treat them as untrusted.
Learn Superglobals ($_GET, $_POST, $_SERVER) in our free PHP course — a beginner-friendly interactive lesson with worked examples, a practice exercise and a…
Part of the free Php course at LearnCodingFast — hands-on lessons with examples you run in your browser, plus practice exercises and a quick quiz.
What You'll Learn in This Lesson
1️⃣ The Superglobal Family
PHP fills several built-in arrays for you on every request, each available in every scope. You'll use $_GET , $_POST , and $_SERVER constantly, with $_SESSION , $_COOKIE , and $_FILES arriving in later lessons. Because they're arrays, you always read them by key.
2️⃣ Reading $_GET (URL Data)
$_GET holds the URL's query-string parameters. Two things to internalise: keys may be missing (so always supply a default with ?? ), and every value arrives as a string (so cast when you need a number).
3️⃣ Reading $_POST (Form Data)
$_POST carries fields from a form submitted with method="post" . The discipline is the same — default missing keys, trim text — plus a non-negotiable step: validate before you trust anything. filter_var() is your friend here.
4️⃣ Inspecting the Request: $_SERVER
$_SERVER describes the request and environment — the HTTP method, host, requested URI, client IP, headers, and more. The most common use is branching on REQUEST_METHOD to decide whether to show a form or process a submission.
5️⃣ The Golden Rule: Never Trust Input ⚠️
Every value in a superglobal came from the client and can be forged . Two attacks dominate: XSS (echoing raw input lets an attacker inject scripts) and injection (putting raw input into SQL or shell commands). The defences: escape on output with htmlspecialchars() , validate or whitelist input, and use prepared statements for databases (covered later).
Now you try. Fill the ___ blanks to read query params safely.
These scrambled lines should safely read and escape a name from the query string. Put them in the order that runs correctly (assume $_GET['name'] = 'Ada' ).
First read the value with a ?? default so a missing key can't error, then trim it, then escape it for safe HTML output, and only then echo. Escaping must happen before output — that's what stops XSS. Output: Hello, Ada .
Predict the output before revealing each answer.
Prints string . All query and form values arrive as strings — cast with (int) when you need a number.
Prints none . The key is missing, so the null-coalescing operator falls back to the default instead of raising an "Undefined array key" warning.
Prints <b>hi</b> — the angle brackets are escaped, so the browser shows literal text instead of running it. This is the core XSS defence.
📋 Quick Reference — Superglobals
Write it yourself, then check against the expected output in the comments. To run it live, serve the file and POST the form data described.
Practice quiz
For the URL ?page=2, what does gettype($_GET['page']) return?
- 'integer'
- 'array'
- 'string'
- 'double'
Answer: 'string'. Every $_GET and $_POST value arrives as a string — cast with (int) when you need a number.
With no ?q in the URL, what does echo $_GET['q'] ?? 'none'; print?
- none
- An 'Undefined array key' warning
- null
- q
Answer: none. The key is missing, so ?? falls back to 'none' without raising an undefined-key warning.
Which superglobal holds data from a submitted <form method="post">?
- $_GET
- $_SERVER
- $_COOKIE
- $_POST
Answer: $_POST. $_POST carries form-body fields; $_GET carries the URL query string.
What does htmlspecialchars('<b>hi</b>') output?
- <b>hi</b>
- <b>hi</b>
- hi
- bold hi
Answer: <b>hi</b>. The angle brackets are escaped so the browser shows literal text instead of running it — the core XSS defence.
Which superglobal would you read REQUEST_METHOD from?
- $_SERVER
- $_GET
- $_POST
- $_SESSION
Answer: $_SERVER. $_SERVER describes the request and environment, including REQUEST_METHOD, HTTP_HOST, and REMOTE_ADDR.
Why should you avoid $_REQUEST?
- It is slower than $_GET
- It does not exist in PHP 8
- It ambiguously merges GET, POST, and COOKIE
- It only holds strings
Answer: It ambiguously merges GET, POST, and COOKIE. $_REQUEST merges $_GET, $_POST, and $_COOKIE; you can't tell the source, and a cookie could override a form field.
What is the safest way to handle a 'sort' parameter from the user?
- Echo it directly into the SQL query
- Whitelist it against an allowed list with in_array
- Trust it because it came over HTTPS
- Cast it to int
Answer: Whitelist it against an allowed list with in_array. Validate or whitelist input: check it against ['name','date','price'] and fall back to a safe default.
How should you treat all superglobal data?
- As safe because PHP fills it
- As already escaped
- As always numeric
- As untrusted user input that can be forged
Answer: As untrusted user input that can be forged. Everything in $_GET, $_POST, $_COOKIE and most of $_SERVER comes from the client and can be forged.
After $page = (int) ($_GET['page'] ?? 1); what is gettype($page)?
- 'string'
- 'integer'
- 'double'
- 'array'
Answer: 'integer'. The (int) cast converts the defaulted value to an integer.
Which pair of habits stops most web vulnerabilities?
- Echo raw, trust everything
- Use $_REQUEST everywhere
- Validate on input, escape on output
- Skip defaults to fail fast
Answer: Validate on input, escape on output. Validate or whitelist input and escape output with htmlspecialchars — two habits that block injection and XSS.