1) Authentication: secure login (minimum standard)

A) Enforce MFA for admins

For any admin user:

• Require MFA (TOTP/authenticator app preferred)

• Enforce MFA again for sensitive actions (role changes, exports, refunds)

B) Strong password + account protection

• Password policy (length + complexity)

• Lockout / cooldown after repeated failed attempts

• Optional breach checks (reject known leaked passwords)

C) Secure sessions (most hacks happen here)

Best practices:

• Use HttpOnly + Secure cookies for session tokens (when possible)

• Short access tokens (5–15 minutes) + refresh tokens with rotation

• Revoke sessions on password change, role change, or logout

• Avoid storing tokens in localStorage if you can

2) Authorization (RBAC): least privilege by design

RBAC means you don’t give “admin” access to everyone.

A) Define roles based on real jobs

Example roles:

• Super Admin (full control)

• Admin (operations + settings)

• Manager (approvals + reports)

• Support (limited actions)

• Viewer (read-only)

B) Define permissions by ACTION (not by screen)

Instead of “access Orders page”, define:

• orders.view / orders.create / orders.update / orders.delete / orders.approve

• refunds.create / refunds.approve

• users.manage

• settings.update

• exports.run

C) Protect “danger zones”

These actions should always require extra controls:

• role/permission changes

• data export (PII)

• deletion of records

• financial actions (refunds, payouts)

• system settings

3) Audit logs: security + compliance + faster support

Logs are how you answer:

• “Who changed the price?”

• “Who exported customer data?”

• “Why did this order get deleted?”

A) Events you must log

• logins/logouts/MFA events/password resets

• role/permission changes

• sensitive actions (refunds, deletions, settings changes)

• exports/downloads (PII)

• approvals and overrides

B) Fields every audit log record should include

• actor_id + role

• action + resource type/id

• timestamp (UTC)

• IP + device/user-agent

• request/trace id

• before/after values (diff)

• result (success/failure)

C) Alerts (don’t wait for someone to notice)

Alert on:

• repeated failed logins

• privilege changes

• mass exports/downloads

• unusual IP / country patterns

• suspicious automation patterns

4) Protection controls: stop attacks early

These are simple controls that block common exploits.

• Rate limiting (login, password reset, API endpoints)

• Brute-force protection (cooldowns + lockouts)

• CSRF protection (if using cookies)

• Input validation + server-side authorization checks (never trust UI)

• IP allowlist for highly sensitive panels (optional but powerful)

• Secure headers (CSP, HSTS, X-Content-Type-Options)

• Secrets management (never hardcode keys; rotate regularly)

5) Backups + Recovery: the “can we restore?” question

A backup is only real if:

• it is encrypted

• stored off-site

• and restore is tested

A) What to backup

• primary database

• file uploads

• secrets/config

• audit log store

• infrastructure as code

B) Schedule + retention (example)

• daily full backup

• hourly incremental for critical systems

• 30–90 days retention

• encrypted backups

• off-site copy (3-2-1 rule)

C) Restore verification (non-negotiable)

• monthly restore test

• define RPO/RTO

• point-in-time recovery

• runbook + owners

• monitoring backup jobs