Web Application Security Basics Every Startup Should Know

You don't need a security team on day one. But you do need to get these basics right, because fixing a breach is way more expensive than preventing one.

Security is one of those things that feels optional until it isn't. Startups move fast, and security work doesn't ship features. But a data breach can kill a company - not just the fine, but the lost trust. The good news: getting the basics right doesn't take long and prevents 90% of common attacks.

The non-negotiables

• HTTPS everywhere, no exceptions. Let's Encrypt makes this free
• Hash passwords with bcrypt or argon2. Never store plaintext. Never use MD5 or SHA for passwords
• Validate and sanitize all user input on the server. Client-side validation is for UX, not security
• Use parameterized queries or an ORM. Raw string concatenation in SQL is how breaches happen
• Set secure, httpOnly, sameSite flags on cookies. Don't store sensitive data in localStorage

Authentication done right

Use a proven library or service for auth. Don't roll your own JWT implementation - the edge cases around token expiration, refresh flows, and key rotation are where vulnerabilities hide. Consider OAuth providers (Google, GitHub, Microsoft) to reduce the amount of credential data you store. Fewer passwords in your database means less to protect.

Enable 2FA for admin accounts at minimum. Use rate limiting on login endpoints to prevent brute-force attacks. Lock accounts after repeated failures. Log every authentication event - successful and failed - so you can detect suspicious patterns.

Cross-site scripting (XSS)

XSS is one of the most common web vulnerabilities. It happens when user-supplied content gets rendered as HTML or JavaScript without being escaped. Modern frameworks like React handle this by default (JSX escapes content), but watch out for dangerouslySetInnerHTML, server-rendered templates, and anywhere you inject user content into HTML attributes or URLs.

Set a Content Security Policy (CSP) header to restrict what scripts can execute on your pages. Start with a restrictive policy and relax it as needed. A good CSP prevents most XSS attacks even if your code has a vulnerability.

API security

• Authenticate every API endpoint. Don't rely on obscure URLs as a security measure
• Authorize at the resource level. Just because a user is logged in doesn't mean they can see other users' data
• Rate limit API endpoints, especially ones that accept user input or return sensitive data
• Don't expose internal IDs in API responses. Use UUIDs for anything user-facing
• Validate request bodies against a schema. Reject unexpected fields
• Set CORS headers explicitly. Don't use Access-Control-Allow-Origin: * on authenticated endpoints

Dependency management

Your application is only as secure as its weakest dependency. Run npm audit (or the equivalent for your stack) regularly and fix critical vulnerabilities. Set up Dependabot or Renovate to open PRs automatically when security patches are available. Remove dependencies you're not actively using - every package is attack surface.

Secrets management

Never commit API keys, database passwords, or secrets to version control. Use environment variables and a secrets manager (AWS Secrets Manager, Doppler, or even a .env file that's in .gitignore). Rotate secrets periodically. If a key is ever exposed in a commit, consider it compromised and rotate it immediately - git history is permanent even if you delete the file.

Where to start today

Run a dependency audit and fix critical vulnerabilities. Add rate limiting to your login and signup endpoints. Set up basic request logging so you can see when something unusual happens. Add a CSP header. These four things take less than a day and immediately improve your security posture.

Ben Arledge

CEO & CTO, CloudOwl