Most SaaS and e-commerce security incidents are caused by the same small set of preventable failures. This guide covers the controls that are most commonly skipped and most likely to be exploited.
Authentication: the most common attack surface
What most teams do: Email + password auth, basic session management, maybe magic links.
What attackers exploit: Password reuse (credential stuffing), weak session token generation, no brute-force protection, no account lockout, no monitoring for suspicious login patterns.
What to actually implement:
- Multi-factor authentication (MFA) — required for admin accounts, strongly encouraged for all users
- Secure session management: short session lifetime, secure + httpOnly + sameSite cookie flags, server-side invalidation on logout
- Rate limiting and lockout: limit failed login attempts, add CAPTCHA after 5 failures, lock accounts after 10
- Breach detection: check new passwords against haveibeenpwned API; notify users when their email appears in known breach data
- Audit logging: record every login event with IP, user agent, and success/failure for anomaly detection
Multi-tenancy: the silent critical vulnerability
If you build a SaaS product serving multiple customers, the most consequential security failure is tenant data isolation. One customer accessing another customer's data is a company-ending event.
Common implementation failures:
- Forgetting WHERE tenant_id = ? in database queries
- Caching responses without tenant context, serving cached data to the wrong tenant
- Not validating that resource IDs (invoice_id=12345) belong to the requesting tenant
- Shared file storage with guessable or sequential file names
Mitigation: Row-level security (RLS) in PostgreSQL enforces tenant filtering at the database level — much more reliable than application-layer checks. For object storage, use non-guessable keys (UUID-based) and presigned URLs with short expiry. Test tenant isolation explicitly in your QA suite: log in as tenant A and attempt to access tenant B's resources via direct API calls.
Dependency management: the fast-moving attack surface
A 2025 study found that 78% of web applications have at least one dependency with a known high-severity vulnerability. Most of these vulnerabilities existed in packages that hadn't been updated in months.
Minimum viable dependency hygiene:
- Automated vulnerability scanning in CI (Dependabot, Snyk, or `npm audit --audit-level=high`)
- Automated PR creation for security patches (Dependabot's auto-PR feature)
- Lock files committed to version control (`package-lock.json`, `requirements.txt` with pinned versions)
- Avoid `latest` version specifiers in production dependencies
- Remove unused dependencies — they're attack surface with no benefit
Data handling: what's stored, what's transmitted
What to never store: Plaintext passwords (bcrypt/Argon2 only), full payment card numbers (PCI DSS prohibits this for most use cases), unencrypted PII at rest on external storage.
What to encrypt: Sensitive PII fields (national ID numbers, health data, financial data) should be encrypted at the column level, not just at disk level. This protects against database exfiltration attacks.
What to minimise: Only collect and retain data you need. Every additional data point is liability. Define and enforce data retention policies — delete what you no longer need.
E-commerce: payment and checkout security
- Never handle card data directly: Use Stripe, Braintree, or Adyen with their hosted payment fields. Card data never touches your servers.
- Validate webhooks: Payment provider webhooks should be validated with signature verification. An unvalidated webhook endpoint can be abused to fake payment confirmations.
- Idempotency: Payment processing should be idempotent — processing the same payment twice shouldn't charge the customer twice. Use idempotency keys.
- Checkout HTTPS only: Enforce HTTPS for all checkout flows. HSTS header (see Security Headers Explained) prevents downgrade attacks.
Monitoring: knowing when something goes wrong
Most breaches go undetected for weeks or months. Real-time monitoring changes this:
- Error rate spikes (often indicate probing or early exploitation)
- Unusual data access patterns (large queries, bulk exports)
- Authentication anomalies (login from new country, many failures then success)
- Unexpected outbound connections from production servers
Use our Website Security Checker for a first pass on your security headers and basic configuration. For a complete security picture, see Cybersecurity Checklist for Small Business.