Web forms & input handling

You've now toured DevTools. This lesson puts that tool to direct use, examining exactly how a web form actually submits data — the entry point for an enormous share of the vulnerabilities covered throughout this entire course.

How a form actually submits data

<form action="/login" method="POST">
    <input type="text" name="username">
    <input type="password" name="password">
    <button type="submit">Log in</button>
</form>

The method attribute determines whether this becomes a GET or POST request (from the HTTP-methods lesson), and action determines where it's sent. Every named <input> becomes a field in the submitted request — genuinely worth opening DevTools' Network tab (from the previous lesson) and watching an actual form submission to see this happen live.

Client-side validation: a UX feature, not a security control

<input type="email" required minlength="5">

HTML form attributes like required, minlength, and type="email" provide immediate feedback to a legitimate user filling out the form correctly — but they run entirely in the browser, meaning an attacker can trivially bypass them by disabling JavaScript, using DevTools to remove the attribute, or simply crafting and sending the HTTP request directly (using a tool like curl, from Path 03) without ever touching the actual HTML form at all.

Client-side validation is a convenience feature for legitimate users, never a security control. Every single check a form performs in the browser must be performed again, independently, on the server — because the server can never actually trust that a request genuinely came from the form it rendered, following the rules that form's HTML happened to specify. This exact principle is the foundation of Path 11's entire web-attacks curriculum and Path 21's API security material.

Hidden fields: convenient, but not confidential

<input type="hidden" name="price" value="49.99">

A hidden field is invisible in the rendered page, but it's still fully present in the HTML source and the submitted request — meaning it's exactly as easy for an attacker to view and modify as any visible field, using DevTools or a simple request-editing tool. A price stored in a hidden field, trusted by the server without re-verification, is a real, recurring vulnerability pattern (previewed here, covered as a full hands-on CTF challenge in Path 19's "Name Your Own Price" challenge).

File upload forms: a genuinely high-risk input type

<input type="file" name="avatar">

File uploads deserve their own specific scrutiny beyond ordinary text input — validating file type based only on the filename extension or the browser-reported content type (both trivially spoofable) rather than actually inspecting the file's real content is a common, exploitable mistake, covered in real depth in Path 11's web application security material.

Why can't a server trust that a submitted form's data followed the validation rules its own HTML specified (like required or minlength)?

Show answerHTML form validation attributes run entirely inside the user's browser — the server only ever sees the final HTTP request that eventually arrives, with no way to verify that request was actually generated by submitting the rendered form through a browser that respected those attributes at all. An attacker can send a perfectly valid-looking HTTP POST request directly (using curl, a browser's DevTools, or a dedicated tool like Burp Suite covered in Path 11) with a completely empty "required" field, an intentionally malformed email, or any other value entirely — the server has absolutely no way to distinguish this from a legitimately-submitted form, because from the server's perspective, they are functionally identical HTTP requests. This is exactly why every meaningful validation check must be duplicated on the server, which is the only place actually capable of enforcing anything.

Key terms

  • Client-side validation — form validation running in the browser, a usability feature that provides no actual security guarantee.
  • Hidden field — a form input invisible in the rendered page but fully present and modifiable in the HTML source and submitted request.

Recap

  • Every input a form collects arrives at the server as a request field, regardless of what type of input control rendered it in the browser.
  • Client-side validation is a UX convenience, never a security control — every meaningful check must be duplicated and enforced on the server, since the server can never trust a request actually respected the browser's rules.
  • Hidden fields and file uploads deserve specific scrutiny, since both are commonly (and mistakenly) trusted more than their actual security properties warrant.

Next up → Content Security Policy Basics