In my video guide Lighthouse Security I carried out a penetration test on the login page, which passed, however, I didn't show you how the new security works in practice.
Lighthouse now includes CSRF mitigation in the login form, that creates a random cryptographic token on every visit the login page.
If you open up developer tools, view source, and select the form, you'll see the generated token.
Try to edit the token, and then login, and it will fail, even if the login details are correct.
Remember, the token is random and changes every time the login page is loaded.
What this means in practice
Copied directly from Gemini response to the question;
"Describe the process a hacker will empty to hack a form, and how the random token helps."
When a hacker "hacks" a form using Cross-Site Request Forgery (CSRF), they aren't necessarily breaking into the server. Instead, they are tricking a legitimate, logged-in user's browser into performing an action they didn't intend to do.
How the Random Token Stops the Hack
The random token (often called an Anti-CSRF Token) adds a "secret handshake" that a hacker cannot replicate.
It’s Invisible to the Hacker: When you load a legitimate form, the server generates a long, random string (the token) and hides it inside the form. Because of a browser security rule called the Same-Origin Policy (SOP), a hacker’s website is forbidden from "reading" the content of the page to see what that token is.
The Server's "Check": When a form is submitted, the server looks for that specific token. It compares the token in the form to the one it has saved for your session.
The Failure Point for the Hacker: If a hacker tries the same "trap" described above, their forged request will not have the correct random token. The server sees the missing or incorrect token and instantly rejects the request as a forgery—even though the login cookies were present.
In short, the token turns a predictable request into an unpredictable one that only the real website can generate.