Authentication vs authorization
- Authentication (authn): who are you? (login)
- Authorization (authz): what may you do? (permissions/entitlements)
Keep authz server-side — StockVision enforces subscription tiers on the API; the client-side gate is only UX.
Sessions vs JWT
| Session (server state) | JWT (stateless) | |
|---|---|---|
| Where state lives | server (Redis/DB) | the signed token itself |
| Revocation | easy (delete session) | hard (need a denylist / short TTL) |
| Scale | shared session store | no lookup, scales freely |
StockVision uses JWTs in httpOnly cookies + short-lived access tokens + rotating refresh tokens — stateless scale with a revocation story via refresh rotation.
Hashing vs encryption (they're not the same)
- Hashing (passwords): one-way. Use bcrypt/argon2 — deliberately slow, salted per-user, so leaked hashes resist brute force. Never reversible.
- Encryption (PII you must read back): two-way. StockVision uses Fernet (authenticated symmetric encryption) for PAN/broker tokens so a DB dump yields ciphertext; the key lives outside the DB.
Passwords are hashed, not encrypted
If you can decrypt your users' passwords, you've already lost. Store a slow, salted hash (bcrypt) and compare hashes. Encryption is for data you need to recover (a PAN, an API token), not for passwords.
OWASP bugs & fixes
| Vuln | What | Mitigation |
|---|---|---|
| XSS | injected script runs in the victim's page | escape/encode output, CSP, httpOnly cookies |
| CSRF | a site rides the user's cookie to act as them | SameSite cookies, CSRF tokens |
| SQL injection | input becomes SQL | parameterized queries / ORM, never string-concat |
| Broken authz | accessing others' data | enforce ownership checks server-side |
| Secrets in code | keys in the repo | env/secret manager, rotate |
The httpOnly-cookie choice is a direct XSS mitigation (script can't read the
token); pair it with SameSite + CSRF tokens to cover CSRF, and a CSP to reduce
XSS impact. StockVision ships security headers + CSP middleware for this reason.