Cybersecurity Fundamentals

Cybersecurity Fundamentals

Security breaches do not just cause data loss — they destroy customer trust, trigger regulatory penalties, and can end a company. Verizon's annual Data Breach Investigations Report consistently finds that over 80% of breaches exploit known vulnerability classes that have well-established mitigations. The majority of attacks succeed because of preventable failures, not sophisticated novel techniques.

The Threat Landscape for Founders

You are not being targeted by nation-state hackers with zero-days. You are being targeted by automated scanners probing for known vulnerabilities, credential stuffing attacks using leaked username/password lists, and phishing campaigns targeting your team members with access to production systems.

The most common breach vectors for small-to-medium businesses:

1. Phishing: fraudulent email convinces an employee to enter credentials on a fake login page
2. Credential reuse: employee uses the same password on your app as on a breached service
3. Exposed secrets: API keys or database credentials committed to a public GitHub repository
4. Unpatched dependencies: a known CVE in a third-party library that was never updated
5. Misconfigured access controls: a storage bucket or database exposed to the public internet

Authentication and Session Security

Never store passwords in plaintext — this is a career-ending error and a legal liability. The correct approach: hash passwords with bcrypt, scrypt, or Argon2 (not MD5 or SHA-1, which are cryptographically broken for this purpose). When a user logs in, hash their input and compare to the stored hash.

For session tokens: generate cryptographically random values (not incrementing IDs, not user IDs). Store them in HTTP-only, Secure, SameSite=Strict cookies. HTTP-only prevents JavaScript from reading the cookie (defeating XSS-based session theft). Secure ensures it is only sent over HTTPS. SameSite=Strict prevents cross-site request forgery.

Implement multi-factor authentication for all internal admin accounts and any account with access to sensitive data. Enforce it, do not make it optional. The 30-second friction of an authenticator app has prevented thousands of account takeovers.

Injection Attacks

SQL injection remains one of the most exploited vulnerability classes despite being trivially preventable. Never concatenate user input into SQL queries. Always use parameterized queries or an ORM that handles parameterization automatically.

The same principle applies to:

• Command injection: never pass user input to shell commands
• LDAP injection: sanitize inputs to directory queries
• NoSQL injection: MongoDB's $where operator can execute arbitrary JavaScript — avoid it

Access Control

Broken access control is the #1 vulnerability class in the OWASP Top 10. The pattern: your app correctly requires authentication (user must be logged in) but does not check authorization (does this user have permission to see this specific record?).

Example: GET /api/orders/7823 returns an order. If the server does not verify that the requesting user owns order 7823, any authenticated user can access any order by changing the ID. This is called Insecure Direct Object Reference (IDOR).

The fix: every data access query should filter by the authenticated user's ID:

SELECT * FROM orders WHERE id = ? AND user_id = current_user_id

Secrets Management

The most common source of catastrophic data breaches at startups: secrets in source code. A database URL with credentials pushed to a public GitHub repo triggers automated scrapers within seconds. The attacker has your data before you notice.

Rules:

• Secrets go in environment variables, never in source code
• Use .env files locally; add .env to .gitignore immediately
• Use a secrets manager (AWS Secrets Manager, Doppler, Vercel's environment variables) for production
• Rotate any secret that may have been exposed, immediately
• Audit your git history for leaked secrets before making a private repo public

Dependency Security

Your application has hundreds of third-party dependencies. Any one of them could contain a known CVE (Common Vulnerabilities and Exposures). Running npm audit or pip-audit weekly identifies known vulnerabilities and their severity. Automate this with GitHub's Dependabot or Snyk, which open pull requests when vulnerable dependencies are detected.

The Log4Shell vulnerability (CVE-2021-44228) in the Apache Log4j library affected hundreds of thousands of applications because of how deep it sat in the dependency tree — many teams did not know they were using it. Knowing your dependency tree is a security responsibility.