Software Security

The OWASP Top 10 is a regularly updated list of the most critical web application security risks. The 2021 edition includes: A01: Broken Access ControlA02: Cryptographic FailuresA03: InjectionA04: Insecure DesignA05: Security MisconfigurationA06: Vulnerable ComponentsA07: Authentication FailuresA08: Data Integrity FailuresA09: Logging FailuresA10: SSRF

XSS is a vulnerability where an attacker injects malicious scripts into web pages viewed by other users. Three types: Reflected: script in URL is reflected back in the responseStored: script is permanently stored on the server (e.g., in a database)DOM-based: script manipulates the page's DOM client-side Prevention: output encoding, CSP, input validation.

Reflected XSS occurs when user input from a request is immediately included in the response without proper encoding. Example: a search page that displays the query parameter without sanitization. Prevention: HTML-encode all outputUse Content-Security-Policy headersValidate and sanitize input

Stored XSS (persistent XSS) occurs when malicious script is saved on the server (e.g., in a database, forum post, or comment) and served to users who view that content. It's more dangerous than reflected XSS because it affects all users who view the page, not just those who click a crafted link. Prevention: sanitize on input, encode on output.

DOM-based XSS occurs entirely on the client side — the vulnerability exists in JavaScript code that processes data from an untrusted source (like location.hash) and writes it to the DOM using unsafe methods like innerHTML or document.write(). The malicious payload never reaches the server. Prevention: use textContent instead of innerHTML, avoid eval().

CSRF tricks a user's browser into making an unwanted request to a site where they're authenticated. Example: a malicious page submitting a hidden form to a banking site. Prevention: CSRF tokens — unique tokens per session/requestSameSite cookie attributeCheck Origin/Referer headersRequire re-authentication for sensitive actions

SQL injection occurs when untrusted input is included in SQL queries without proper sanitization, allowing attackers to execute arbitrary SQL. Example: SELECT * FROM users WHERE name = '' OR '1'='1'. Prevention: Parameterized queries: WHERE name = ?Use an ORMInput validation and escapingPrinciple of least privilege for DB accounts

Parameterized queries (prepared statements) separate SQL code from data by using placeholders for user input. The database engine treats parameters as data, never as executable code.
Example: db.query("SELECT * FROM users WHERE id = ?", [userId])
This is the primary defense against SQL injection, supported by all major databases and ORMs.

Authentication (AuthN): verifies who you are — login with username/password, biometrics, MFAAuthorization (AuthZ): determines what you can do — permissions, roles, access control Authentication always comes first. Example: logging in proves your identity (authentication); your role determines which pages you can access (authorization).

OAuth 2.0 is an authorization framework that allows third-party applications to access a user's resources without exposing their credentials. Key grant types: Authorization Code: for server-side apps (most secure)PKCE: for SPAs and mobile appsClient Credentials: for machine-to-machineRefresh Token: for obtaining new access tokens

The Authorization Code flow: App redirects user to authorization serverUser authenticates and grants consentServer redirects back with an authorization codeApp exchanges the code for an access token (server-to-server)App uses the access token to call APIs Most secure flow because tokens never pass through the browser.

A JWT is a compact, URL-safe token format for securely transmitting claims between parties. Structure: header.payload.signature
Header: algorithm and token typePayload: claims (user data, expiry)Signature: verifies integrity using HMAC or RSA JWTs are stateless — the server doesn't need to store session data. Base64Url encoded, not encrypted by default.