B2What the client asks
“What happens if we get hacked?”
Rate limits. Brute-force lockouts. A second factor. Encryption for the columns that deserve it. A credible answer when a credential leaks.
What actually goes wrong
The question is asked once, early, and answered with a sentence. The work behind the sentence is weeks, and it is invisible, so it is the first thing cut when a feature is due.
The sign-in form alone needs a rate limit, a lockout, a growing delay, and a locked account that answers exactly like a wrong password, or it becomes an oracle for discovering who has an account.
What Grit does about it
- Sessions are server-side, so a device can be revoked and a reused refresh token kills the chain it came from.
- The sign-in form has four layers, including the one people miss: a locked account answers like a wrong password, on the same timing.
- A security suite with a firewall, rate limiting and an anomaly log is mounted at /sentinel, with its threat log in your own database.
The commands
Check the configuration before you deploy
grit doctor
Already running
grit start# http://localhost:8080/sentinel
What it does not do
None of it protects a leaked admin password that nobody rotates, or a server nobody patches. A framework can close the application’s doors, not the operational ones.