Forms — Handling GET and POST Properly

The superglobals you'll use

"Superglobal" means: they're automatically available in every scope, no imports or declarations needed. PHP just puts them there for you when a request comes in.

• $_GET — URL query parameters (?id=42&sort=desc)
• $_POST — form body data, for forms with method="post"
• $_REQUEST — both GET and POST merged. Don't use this — be explicit.
• $_FILES — uploaded files
• $_COOKIE — cookies the browser sent
• $_SESSION — server-side session storage (next chapter)
• $_SERVER — request headers, server info, environment variables

All of these are arrays. All are populated by PHP before your code starts running. And critically: all contain untrusted input from the outside world. Treat the values as hostile until you've validated them.

Mental model: incoming user data is like packages arriving at a warehouse. You don't just throw them on shelves — you inspect first. Is this what we expected? Is anything suspicious? Then sort and store. The "inspect" step is validation. The cost of forgetting this step is bugs at best, security holes at worst.

🐍 Python (Flask): If you've used Flask, $_GET ≈ request.args, $_POST ≈ request.form, $_FILES ≈ request.files, $_SESSION ≈ session, $_COOKIE ≈ request.cookies, $_SERVER ≈ request.headers + request.environ. PHP exposes them as globals; Flask gives you a request object.

A simple HTML form

<form method="post" action="/submit.php">
  <label>Name: <input name="name" type="text"></label>
  <label>Age:  <input name="age"  type="number"></label>
  <button type="submit">Send</button>
</form>

Key things to notice. method="post" submits using a POST request — body data, not URL parameters. action="/submit.php" says where the form posts to. The name="..." attributes on inputs are what become keys in $_POST on the server. No name → no value submitted. Tiny detail, big effect.

The four-step pattern — drill this into muscle memory

Every form handler follows the same four-step structure. Drill this:

<?php
declare(strict_types=1);

if ($_SERVER['REQUEST_METHOD'] !== 'POST') {
    http_response_code(405);
    exit('Method not allowed');
}

// 1. Default — never assume the key exists
$name = trim($_POST['name'] ?? '');
$age  = (int) ($_POST['age']  ?? 0);

// 2. Cast — already done above with (int)

// 3. Validate
$errors = [];
if ($name === '')           $errors[] = 'Name is required.';
if (mb_strlen($name) > 100)  $errors[] = 'Name too long.';
if ($age < 0 || $age > 150)  $errors[] = 'Age looks wrong.';

if ($errors) {
    http_response_code(400);
    foreach ($errors as $e) echo "<p>" . htmlspecialchars($e) . "</p>";
    exit;
}

// 4. Use — only after validation passes, use the data
echo "Hello, " . htmlspecialchars($name) . " (age $age).";

The pattern: default → cast → validate → use. Default protects against missing keys. Cast turns strings into the type you expect. Validate checks the data is reasonable. Use happens only after validation succeeds. Skip a step at your peril. Every form handler in every PHP app you ever write follows this shape.

GET for navigation, POST for actions

Foundational web rule that's worth understanding deeply: GET requests must be safe and idempotent.

• "Safe" means GET shouldn't change anything on the server.
• "Idempotent" means hitting the URL twice does the same thing as hitting it once.

Why does this matter? Because browsers, search engines, link-checkers, and previewers all freely "follow" GET URLs to see what's there. If you put "delete this post" behind a GET URL, you'll wake up one day to a wiped database — Google's crawler will have helpfully clicked every delete link as it indexed your site.

• GET: reading a page, filtering a list, navigating tabs, search queries. Bookmark-friendly.
• POST: create, update, delete. Anything that mutates state.

This isn't just convention. It's how the entire web works at a deeper level. Follow it.

Repopulate forms on validation failure

Users absolutely hate retyping. If validation fails, render the form again with the values they submitted, so they only have to fix the broken bits:

<input name="name" value="<?= e($_POST['name'] ?? '') ?>">

CRITICAL detail: escape the value with htmlspecialchars (the e() helper). The user might have typed "><script>...</script> as their name (yes, people really test this — sometimes for fun, sometimes for malicious reasons). Without escaping, you've just opened an XSS hole.

CSRF — the attack you don't see coming

Settle in for a quick security story, because this one matters.

Picture this attack scenario: an attacker sends you a link to cute-cats.html. You click it because, cats. The page looks innocent, but in the background it has a hidden form that auto-submits to your-bank.com/transfer?to=attacker&amount=9999. Since you're already logged into your bank, your browser includes your login cookies with the request. Your bank sees a valid authenticated request and processes it. You just lost $9999 because you wanted to look at cats.

That's CSRF (Cross-Site Request Forgery). The attacker doesn't need your password — they just need to trick your browser into making a request while you're authenticated somewhere.

The fix: include a secret token in every form that an attacker on another site can't possibly know. Then verify the token on submission.

// On the form-render side
session_start();
if (empty($_SESSION['csrf'])) {
    $_SESSION['csrf'] = bin2hex(random_bytes(32));
}
?>
<form method="post">
  <input type="hidden" name="csrf" value="<?= e($_SESSION['csrf']) ?>">
  <!-- ... -->
</form>
<?php

// On the form-handler side
if (!hash_equals($_SESSION['csrf'] ?? '', $_POST['csrf'] ?? '')) {
    http_response_code(403);
    exit('CSRF token mismatch');
}

How it works: on the form page, generate a random token and store it in the user's session. Include it in the form as a hidden field. On submission, check the token in the form matches the session. An attacker on a different site can't read your session data, so they can't include the right token. Even if they trick your browser into making the request, it fails the token check.

Use hash_equals for the comparison, not ===. hash_equals does constant-time comparison, which prevents "timing attacks" where an attacker measures how long the comparison took to gradually guess the token character by character. Tiny cost, real protection. Yes, even on tiny personal apps. The habit is cheap; not doing it is dangerous.

File uploads

Forms can also upload files. Two things change from a regular form:

<form method="post" enctype="multipart/form-data">
  <input type="file" name="avatar">
  <button type="submit">Upload</button>
</form>

The enctype="multipart/form-data" is critical — without it, browsers only send the filename, not the actual file bytes. Easy thing to forget; impossible to debug if you don't know about it.

On the server, uploads land in $_FILES:

<?php
if ($_FILES['avatar']['error'] !== UPLOAD_ERR_OK) {
    exit('Upload failed: ' . $_FILES['avatar']['error']);
}

$tmp  = $_FILES['avatar']['tmp_name'];     // temp path PHP saved it to
$name = $_FILES['avatar']['name'];          // user-provided filename — DO NOT trust
$size = $_FILES['avatar']['size'];          // bytes
$type = mime_content_type($tmp);            // detect actual mime from content

if ($size > 5_000_000) exit('Too big');
if (!in_array($type, ['image/jpeg','image/png','image/webp'], true)) {
    exit('Not an image');
}

// Generate a safe destination name — never use the original filename
$ext  = match($type) {
    'image/jpeg' => 'jpg',
    'image/png'  => 'png',
    'image/webp' => 'webp',
};
$dest = __DIR__ . '/uploads/' . bin2hex(random_bytes(8)) . ".$ext";

if (!move_uploaded_file($tmp, $dest)) {
    exit('Save failed');
}

Security notes worth absorbing:

• Don't trust the user's filename. Attackers love naming files "image.png.php" — Apache might serve it as PHP code, instantly compromising your server. Always rename uploaded files to a name YOU generate.
• Use mime_content_type to detect the real type from file contents, not the user's claim. Extensions and MIME headers are easy to fake.
• Validate size BEFORE doing anything else. Otherwise an attacker can upload 10 GB files and DoS your disk.
• Store uploads OUTSIDE the web root when possible, and serve them through a controller. Nothing the user uploads can ever be executed as PHP that way.

POST-Redirect-GET — the pattern

After a successful POST, redirect to a GET page. Don't render content directly from the POST handler.

// after successful save
header('Location: /thanks.php');
exit;

Why? Because if the user hits "back" or "refresh" after a POST, the browser asks "want to resubmit the form?" Most users will click yes without reading. That means double-submits — duplicate records, duplicate emails, duplicate payments.

By redirecting to a GET page after the POST, the user's browser history shows the GET URL, not the POST. Hitting back/refresh just reloads the result page, doesn't resubmit. Smooth UX, no duplicate writes.

The exit; after header() is mandatory — without it, PHP continues executing the rest of the page, which can produce output before the redirect actually takes effect (depending on output buffering). Always pair them.