Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more

When you submit a form, the browser sends an HTTP request; the application checks and processes it, may query a database, then returns an HTTP response. A secure, well-designed path validates the request at each relevant boundary—especially identity, permission, browser-origin protections, input, and database access. The exact components vary by application: this is a representative path, not a requirement that every site use the same proxy, identity system, server, or database.

What happens to one request after you click Submit?

  1. The browser builds an HTTP request

    The request includes a method, a target such as a URL, headers, and sometimes a body containing submitted data. A page may trigger several requests to fetch the resources it needs; one click does not necessarily mean one request. HTTP follows a client-server model: the browser (the client) sends a request and receives a response. MDN’s HTTP overview explains the request-and-response model.

  2. The network carries it to a server

    HTTP is an application-layer protocol. It can travel over TCP, including TCP protected by TLS. Routers relay network traffic, and application-level proxies may also be involved. DNS lookup, connection setup, and TLS negotiation are not necessarily repeated for every HTTP request: connections can be reused, and the details depend on the protocol and deployment. MDN’s HTTP guide covers HTTP’s role and behavior.

    Free tools Windows power users keep installed

    One-click scans. No signup required.

    Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.
  3. An intermediary may handle it first

    A proxy or other intermediary may filter, authenticate, log, or route a request, and some proxies can modify it. A cache may have a usable response and serve it without sending the request to the application’s origin. If the request does reach the application, it may therefore arrive after infrastructure has already handled it.

    #1 Best Overall
    Sale
    Pearson Computer Networking, 8E
    • brand: Pearson
    • Computer Networking, 8e
  4. The server routes and parses the request

    The server or application framework matches the request to a route and parses its headers and body. The application should reject malformed or unsupported input and enforce the endpoint’s expected request size and content type. The precise limits and defaults are stack-specific; they are implementation checks, not universal rules for every HTTP server.

  5. The application checks identity, permission, and data

    Before performing a sensitive operation, the application establishes who is making the request, checks whether that caller may perform the requested action on the particular resource, and applies any relevant browser-context protections. It then validates submitted data and business rules on the server. These checks are not interchangeable: passing one does not automatically pass the others.

  6. The application makes a database call

    Only after the applicable checks succeed should the application issue a database operation. User-provided values must remain data, not be interpreted as part of a SQL command; strongly typed parameterized queries are a key safeguard.

    Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.
  7. The application turns the result into a response

    The application handles the database outcome and constructs an HTTP response with a status, headers, and possibly a body. Intermediaries may handle the response on its way back. The browser then processes it, which may include displaying a result or making additional requests.

Which checks should happen before a database operation?

Authenticate the caller

Authentication answers “Who is making this request?” HTTP supports challenge-response authentication, and applications commonly use cookies to associate requests with session state. HTTP itself is stateless: the protocol does not inherently remember a user between requests. MDN’s HTTP authentication guide describes HTTP authentication mechanisms.

Basic authentication credentials are Base64-encoded, not encrypted. TLS is needed to protect them from interception in transit. More generally, use HTTPS to protect the transport; OWASP’s Transport Layer Security Cheat Sheet also explains how HSTS helps browsers continue using HTTPS for covered hosts.

Authorize this action on this resource

Authorization answers “May this identified caller do this?” Check the requested operation against the specific resource and caller. Being logged in does not, by itself, grant permission to read or change every record.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

Enforce CSRF protection for cookie-authenticated changes

When cookies authenticate state-changing requests, validate a CSRF token on every protected request. Keep GET, HEAD, and OPTIONS free of state changes. Client-side framework behavior does not replace server-side token validation. OWASP notes that authentication and authorization must be implemented before CSRF checking can be effective; see its CSRF Prevention Cheat Sheet.

Validate data and workflow on the server

Check submitted values against the endpoint’s expected types, ranges, formats, and business rules before using them. Browser-side validation can improve usability, but it cannot be the security boundary: a caller can send a request without using the page’s interface. Reject invalid input rather than proceeding to a database command. The right validation rules depend on the application and the operation; there is no universal set of form rules.

Use safe database access

Use strongly typed parameterized queries so values are passed separately from SQL syntax. Do not build SQL by concatenating untrusted input, and do not hard-code database connection strings in application code. OWASP’s Secure Database Access guidance recommends query parameterization to prevent untrusted input from being interpreted as part of a SQL command. Its SQL injection testing guide explains the injection risk.

Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Support on Ko-Fi

What should the application do with database results and errors?

A database call can succeed, find no matching record, encounter a constraint violation, time out, or fail for another reason. The application should handle these outcomes deliberately: return the appropriate application-level result, avoid treating an error as a successful change, and avoid exposing raw database details to the user. Database access should use an account with only the privileges the application needs. The exact privilege setup and error policy depend on the chosen database and application.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

How should the response return to the browser?

Construct a response with the intended status, headers, and body, then account for any proxy or cache that may handle it on the way back. When response content includes untrusted data, encode or sanitize it for the output context so it is not treated as executable content. Where cookies are used, set appropriate cookie protections. These are application and deployment choices; the right settings depend on what the response contains and how the session works. MDN’s web security overview provides background on security risks and defenses.

Which parts of this path can differ?

A small application may handle routing and database access in one service; a larger deployment may add proxies, caches, load balancers, or separate identity services. Some requests never reach the origin because a cache can answer them. Connection reuse also means the network setup is not necessarily repeated for each request. The checks still need to be assigned to the appropriate layer and enforced consistently: infrastructure can provide useful controls, but it does not make endpoint-level authorization, server-side validation, or safe database access unnecessary.

Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.