Learning Material

Cybersecurity Essentials Every Developer Should Know

Learning Material · Security

Cover: Cybersecurity Essentials Every Developer Should Know

Most breaches aren't exotic

The OWASP Top 10 — a list maintained by security researchers of the most common web vulnerabilities — has looked broadly similar for years: injection attacks, broken authentication, exposed sensitive data. Most breaches aren't zero-day exploits; they're these same well-known mistakes, still unfixed.

SQL injection: still not extinct

// Vulnerable
const query = `SELECT * FROM users WHERE email = '${email}'`

// Safe: parameterized query
const query = 'SELECT * FROM users WHERE email = ?'
db.execute(query, [email])

If email comes from user input and gets concatenated directly into SQL, an attacker can submit ' OR '1'='1 and change the query's meaning entirely. Parameterized queries treat user input strictly as data, never as executable SQL — this single habit eliminates the entire vulnerability class.

Cross-site scripting (XSS)

// Vulnerable: renders raw HTML from user input
element.innerHTML = userComment

// Safer: renders as plain text
element.textContent = userComment

If a user's comment can include <script> tags and gets rendered as raw HTML on another visitor's page, that script runs with the same permissions as the site itself — reading cookies, submitting forms, anything JavaScript can do. Modern frameworks (React, Vue) escape output by default, which is a large part of why XSS has declined — but any spot using dangerouslySetInnerHTML, v-html, or raw innerHTML reopens the risk.

Broken authentication

Weak password policies, missing rate-limiting on login attempts, and session tokens that never expire are all "broken authentication." A login endpoint with no rate limit lets an attacker try millions of password guesses per hour with no resistance — adding a delay or lockout after repeated failures closes that door almost entirely.

Sensitive data exposure

Storing passwords in plain text, transmitting data over plain HTTP instead of HTTPS, or logging full card numbers are all forms of this. Passwords should be hashed with a slow, purpose-built algorithm (bcrypt, argon2) — never encrypted, and never stored plainly — so that even a full database leak doesn't hand over usable credentials.

Defense in depth. No single practice covers everything. Input validation, parameterized queries, output escaping, HTTPS everywhere, and rate limiting each close a different door — a real application needs several of these working together, not just the one that felt most urgent that week.

The habit that matters most

Treat all user input as hostile by default — every form field, URL parameter, uploaded file, and API payload. Nearly every vulnerability above comes from trusting input that should have been validated, escaped, or parameterized first.

Comments