How to Fix Common Form Security Issues

None of these individually looks like a crisis - a form method, an autocomplete attribute, a missing file-type restriction. But each is a small, well-documented mistake that shows up on a huge share of real sites, and each has a direct, unambiguous fix.

The Issues, One at a Time

Login forms submitted via GET

Credentials end up in the URL - browser history, server access logs, and referrer headers all capture them in plaintext.

<!-- Wrong -->
<form action="/login" method="GET">

<!-- Correct -->
<form action="/login" method="POST">

Forms submitting to HTTP from an HTTPS page

Even if the page itself is secure, a form action pointing at http:// is the same mixed content problem applied to a form submission, and it sends the submission in plaintext. Audit every form's action attribute, not just the page URL itself.

Credentials submitted cross-domain

A login form posting to a third-party domain (a legacy integration, an old vendor endpoint) sends credentials somewhere your own security controls don't cover. If it's not your domain and not a trusted, audited identity provider, treat it as a finding to investigate.

File uploads with no MIME type restriction

<input type="file" accept=".jpg,.jpeg,.png,.pdf" />

The accept attribute is a UX hint only - the actual security control has to be server-side validation of the file's real content type, not just its extension or the client-supplied MIME type.

Password fields with autocomplete disabled

<!-- Avoid -->
<input type="password" autocomplete="off" />

<!-- Preferred -->
<input type="password" autocomplete="current-password" />

How Scanverra Detects These

Scanverra's security scan parses every form on your site and checks its method, action target, autocomplete attributes, and file-input restrictions, flagging each specific issue found - from a critical (credentials over HTTP) down to a low-severity note (autocomplete disabled) - rather than a single undifferentiated "form issues" warning.