🛡️ Protection Against Common Attacks

A Perspective on Vulnerability Prevention

To a Programmer, common attacks like XSS or SQLi are the result of “Implicit Trust.” We secure systems by moving toward “Explicit Validation”—ensuring that every boundary in our system treats data as potentially executable and therefore dangerous.

---

1. The Mindset: Systemic Immunity

Instead of playing “whack-a-mole” with individual vulnerabilities, we build systems that are immune to them by design.

• Boundary Control: Every layer (Frontend, API, Database) must independently verify the integrity of the data it receives.
• The “Data vs. Code” Separation: Most attacks succeed because the system confuses data (a user’s name) with code (a database command or a script). Our job is to keep them strictly separated.

---

2. Core Attack Vectors and Strategic Defenses

A. SQL Injection (SQLi)

The goal is to trick the database into executing malicious queries.

• The Approach: Abandon string concatenation entirely. Use Parameterized Queries or a trusted ORM.
• Least Privilege: The database user for the application should not have permissions to drop tables or access system schemas.

B. Cross-Site Scripting (XSS)

The goal is to inject malicious scripts into a victim’s browser via your application.

• The Approach: Implement a strict Content Security Policy (CSP) to block unauthorized scripts.
• Output Encoding: Treat all user-generated content as plain text, encoding it before rendering it in the DOM.

C. Cross-Site Request Forgery (CSRF)

The goal is to trick an authenticated user into performing an action they didn’t intend to.

• The Approach: Use Anti-CSRF Tokens for state-changing requests (POST, PUT, DELETE).
• Cookie Security: Set SameSite=Strict or Lax on all authentication cookies to prevent them from being sent during cross-site requests.

D. Server-Side Request Forgery (SSRF)

The goal is to trick the server into making requests to internal or unintended resources (like metadata services).

• The Approach: Implement a strict Allow-list for any outbound requests made by the server.
• Network Isolation: Use VPCs and security groups to ensure the application server cannot reach internal administrative ports.

---

3. Automation and Verification

A Programmer knows that manual checks will eventually fail.

• SAST/DAST: Integrate static and dynamic analysis into the CI/CD pipeline to catch vulnerabilities before they reach production.
• The “Security Linting” Habit: Use linters that flag dangerous functions (like eval() or raw SQL strings) in real-time.
• Dependency Audits: Use tools to monitor third-party libraries for known CVEs, as these are frequent entry points for common attacks.

---

4. Programmer Checklist: The Protection Audit

• SQLi: Is every single database interaction using parameterized queries?
• XSS: Does our CSP block unsafe-inline scripts?
• CSRF: Are all state-changing endpoints protected by tokens or SameSite cookies?
• SSRF: Have we blocked our server from accessing 169.254.169.254 (cloud metadata)?
• Error Handling: Do our error messages hide technical details (like stack traces) from the end-user?

---

“Junior programmers fix vulnerabilities. Senior programmers design systems where those vulnerabilities are impossible to create.”

---