Here is how I think through common web security mistakes
I built this page to make my security thinking visible instead of just listing “authentication” or “secure coding” as skills. You can test password feedback, route decisions, secret handling, and role permissions to see where I draw the line between normal frontend behavior and security that must be enforced on the server.
Hands-On Demos
4
Approach
Defensive
Real Secrets Stored
Never
Default Decision
Deny
What I am trying to prevent
The failures behind these demos
These are not random widgets. Each one maps to a real class of mistake: weak credential guidance, broken access control, leaked secrets, and accounts with more power than they need.
Deny by default
If the session, role, or route requirement is unclear, I would rather block the action than guess and expose something.
Enforce it on the server
Hiding a button is not security. Protected reads, writes, exports, and role checks still need server-side enforcement.
Keep secrets out of the browser
Public environment variables are visible to users. Private keys, service credentials, and tokens belong behind a server boundary.
Give every role only what it needs
The smaller the permission set, the smaller the damage if an account or session is misused.
Password Auditor
I can score the input without ever keeping it
Type a sample password and the checks run entirely in your browser. I do not send it to an API, save it, log it, or place it in local storage. This is the kind of feedback I would use to guide a user without collecting more sensitive data than I need.
Strength
0/100
Rating
Waiting
Length
0
Checklist
Why I built this
I wanted to show the decisions behind the code, not just a list of security buzzwords.
This lab shows how I think about credentials, sessions, route protection, secret exposure, and least privilege. It is still a portfolio demo and not just a penetration testing suite. However, the rules behind it are the same ones I would carry into a real application: collect less, expose less, verify on the server, and deny access when the state is uncertain.
Everything here is defensive and uses local demo data only.