Forms & UI Inventory — Login, Contact & Payment Forms

Forms are where visitors hand you their data

Every form on your site — login, contact, checkout, newsletter signup — is a point where a visitor trusts you with information. This module builds an inventory of every form type detected and checks for one particularly important, often-overlooked gap: CSRF protection.

What is CSRF, in plain terms?

Cross-Site Request Forgery is an attack where a malicious site tricks a visitor's browser into submitting a form on your site without them realizing it — for example, silently submitting a "change password" or "transfer funds" request while the visitor is simply browsing an unrelated malicious page, relying on the fact that their browser is already logged into your site. CSRF tokens are a defence: a unique, unpredictable value embedded in your form that the malicious site has no way of guessing or including.

What's reported

• Form detection — login, contact, payment, and other form types found on the page.
• Password field count — how many password inputs exist across all forms, distinct from just knowing a login form is present.
• CSRF token fields (informational only) — whether state-changing forms (login, registration, payment, contact, newsletter) include a hidden field matching common CSRF token naming patterns. This is a low-reliability signal, shown for transparency rather than as a pass/fail verdict — many correctly-protected forms rely on SameSite cookies (checked separately in the Cookie Security module) instead of a hidden token field, which this check cannot detect at all. Absence here does not confirm a real vulnerability.

How to fix it

Most modern web frameworks (Django, Rails, Laravel, and popular CMS platforms) include CSRF protection by default or as a one-line addition. If you're hand-coding forms, adding a per-session CSRF token is a standard, well-documented pattern your developer can implement directly.