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

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

Always POST for anything containing credentialshtml

1<!-- Wrong -->
2<form action="/login" method="GET">
3
4<!-- Correct -->
5<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://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

Restrict accepted types on the client, and re-validate server-sidehtml

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

The acceptattribute 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

Let password managers do their jobhtml

1<!-- Avoid -->
2<input type="password" autocomplete="off" />
3
4<!-- Preferred -->
5<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.

FAQ

Frequently asked questions

Why does submitting a login form over GET matter if the connection is HTTPS?

HTTPS encrypts the connection, but GET parameters end up in the URL - which gets logged by the browser's history, the server's access logs, any reverse proxy in between, and referrer headers sent to third-party resources on the next page. The credentials end up recorded in plaintext in places that have nothing to do with the connection's encryption.

Is disabling browser autocomplete on a password field actually a security improvement?

Generally no, and it can be counterproductive - it pushes users toward weaker, memorable passwords or writing them down, since they can't rely on a password manager's autofill. Password managers are a net security win; disabling autocomplete fights against using one.

What's the actual risk of a form missing a file-type restriction?

An unrestricted upload field can accept an executable or script file that, depending on how the server stores and serves uploads, might end up executable on the server or served with a MIME type the browser interprets as HTML/JS - turning a file upload feature into a code-execution or stored-XSS vector.

Should I ever disable HTML5 form validation with novalidate?

Only if you're replacing it with equivalent (or better) custom validation, and you must validate server-side regardless either way - client-side validation, HTML5 or custom, is a UX convenience, never a security control on its own.

Check your forms for free

Run a security scan and see every form security issue Scanverra finds on your site.

Run free audit