Web Form Security: Preventing CSRF, Open Redirects, and Insecure Submissions

Why Forms Are a High-Value Target

Web forms are where your users take actions — logging in, submitting payments, changing account details. That makes them a prime target for two types of attacks: Cross-Site Request Forgery (CSRF), where an attacker tricks a user into submitting a form action without knowing it, and insecure redirect handling, where a form's success redirect can be manipulated to send users to a malicious destination.

When WebSentry scans your site, the form security check looks at whether your forms include CSRF tokens, whether your redirects are validated, and whether forms are submitted over HTTPS.

Cross-Site Request Forgery (CSRF)

How it works

CSRF exploits the fact that browsers automatically include cookies — including session cookies — with every request to a domain, regardless of where the request originated.

An attacker creates a hidden form on their own site that submits a POST request to your application. If a logged-in user visits the attacker's page, the request fires with their session cookie — and your server can't tell it apart from a legitimate form submission.

The fix: CSRF tokens

A CSRF token is a secret, unpredictable value generated server-side and embedded in each form. When the form is submitted, the server checks that the token matches. An attacker on another origin can't read the token, so they can't forge a valid request.

<form method="POST" action="/transfer">
  <input type="hidden" name="csrf_token" value="{{ csrf_token }}">
</form>

Most frameworks handle this automatically:

• Django: {% csrf_token %} in every form template
• Rails: protect_from_forgery is on by default
• Laravel: @csrf blade directive
• Express: use the csrf-csrf middleware

SameSite cookies as a complementary defence

Setting SameSite=Lax or SameSite=Strict on your session cookie stops browsers from sending it on cross-site requests at all. Use both: CSRF tokens as your primary defence, SameSite cookies as a backup. See our cookie security guide for details.

Open Redirects After Form Submission

Many forms redirect users after a successful submission. If that destination comes from user input without validation, an attacker can direct a newly-logged-in user straight to a phishing page. Only redirect to relative paths or a whitelist of known domains. Never follow an arbitrary URL from form input or query parameters.

Forms Must Be Submitted Over HTTPS

Any form on an HTTP page — or a form whose action attribute points to an HTTP URL — sends data in plaintext. Passwords and personal details are visible to anyone on the same network. Ensure your entire site runs on HTTPS and add HSTS to prevent browsers from ever loading your pages over HTTP.

Quick Checklist

• ✓ All state-changing forms include a CSRF token
• ✓ Session cookies use SameSite=Lax or Strict
• ✓ Post-form redirects validate destination URLs
• ✓ All forms are served over and submitted to HTTPS
• ✓ Server-side validation on all inputs
• ✓ Re-scan with WebSentry after changes

Summary

CSRF tokens, SameSite cookies, validated redirects, and HTTPS together close the most common form-based attack vectors. Most frameworks handle CSRF automatically — confirm it's enabled, add SameSite flags to your session cookies, and make sure your post-form redirects don't trust unvalidated input.