A web form checks in the browser that the email field is well formed and the quantity is a positive number, which cuts round trips to the database. A developer proposes removing the server-side validation because the browser already checks. What should the DBA advise?
Select an answer to reveal the explanation.
Short Explanation
Client-side checks are a polite sign on the door; server-side checks are the lock. The browser check is great for a quick, friendly error message, but anyone can skip it by sending a request directly. So you keep both, and you never trust the browser alone.
Full Explanation
Client-side scripting runs on the user's device, typically in the browser, and is valuable for responsiveness: it catches obvious mistakes before a request is sent, reducing round trips and server load. However, the client is fully under the user's control. Scripts can be disabled or modified, and requests can be crafted with tools that never run the form at all, so client-side checks provide convenience, not enforcement. Server-side validation in the application, together with database constraints such as data types, NOT NULL and CHECK constraints, is what actually protects data integrity. Client-side scripts do not run with the database account's privileges; they run in the user's browser and only send requests to the server, which then decides what to execute. Browser validation does not enforce table constraints; the database knows nothing about checks performed in a browser and applies its own rules when data arrives. Numeric fields are as easy to alter as text fields once a request is intercepted or crafted, so no data type is safe from bypass. Exam caveat: the objectives contrast runtime locations, and the takeaway is that client-side scripting complements but never replaces server-side controls. Operational check: send a request directly to the endpoint with a negative quantity and a malformed email, bypassing the form, and confirm the server rejects both values.