Client-Side Security Is an Illusion

Every client-side "security" measure is trivially bypassable — the server is where trust lives

Password Fields in GET Requests

This section demonstrates that every client-side "security" measure is trivially bypassable. Open your browser's DevTools (F12) and try it yourself.

A password field (<input type="password">) hides the characters on screen, but if the form uses GET, the password appears in plain text in:

  • The URL bar
  • Browser history
  • Server access logs
  • The HTTP Referer header when you navigate away

Hidden Fields Are Not Hidden

The <input type="hidden"> element is invisible on the page, but:

  • Visible in "View Source"
  • Visible and editable in DevTools
  • Sent in the HTTP request like any other field

Client-Side Restrictions Are Decorative

maxlength="5", readonly, disabled — all trivially removed via DevTools. These attributes are UX conveniences, not security measures.

Data Collection Zones

Data on the web exists in four zones, each with different security properties:

Zone Who Controls It Security Level
Client (browser) The user (and any extensions/scripts) Zero trust — user can modify anything
Transit (network) ISPs, routers, proxies HTTPS encrypts; HTTP is plaintext
Server You (the developer/operator) Trusted — this is where validation lives
Third-party (external scripts, CDNs) Someone else You're trusting their code in your page

Client-Side Storage and Third-Party Scripts

localStorage and sessionStorage let you store data in the browser, but any JavaScript on the page — including third-party scripts — can read it all:

Live demos:

  • storage1.html — Save a "secret message" to localStorage or sessionStorage
  • storage2.html — Navigate here and see your secret is still accessible. Notice the "harmless" third-party script that reads everything.

The "Harmless" Third-Party Script

The storage2.html page includes an external JavaScript file. That script iterates through all localStorage and sessionStorage keys, collects every value, and logs them. In a real attack, it would fetch() them to a remote server. This is how third-party scripts exfiltrate data — and you invited them onto your page.