Web Programming

This page explains, in gentle terms, why code running in a browser cannot be treated as a security boundary.

Goal: understand that users can change browser-side checks, and learn why authentication, authorization, and input validation belong on the server.

Client-side JavaScript tampering

JavaScript runs on the client: the user's browser. The user can inspect, disable, replace, or add to that code with browser tools. This is normal control of their own browser, so a site must not use client-side code alone to protect data or enforce important rules.

Why can it be changed?

The browser receives HTML, CSS, JavaScript, and data in order to display a page. The person using the browser can also send requests without running the page's JavaScript at all.

Example: bypassing a form check

if (age < 18) {
  alert("You must be 18 or older");
  return false;
}

This check can improve the user experience, but it is not proof of age. A modified browser or another program can send a different value directly to the server.

What must the server check?

• Whether the user is authenticated and allowed to perform the action.
• Whether submitted values have the expected type, range, and format.
• Whether the action follows the application's business rules.
• Whether prices, roles, user IDs, and other sensitive values are calculated or verified server-side.

Disabled buttons, hidden fields, and obfuscated JavaScript do not keep secrets. Use client-side checks to show helpful errors quickly, then repeat all security-relevant checks on the server. Use HTTPS and protections such as CSRF defenses where they fit the service.

Related topics