"AppSec Series #1: Introduction to Application Security — Mindset, CIA Triad and Threat Landscape"

The Application Security Engineer Series

This series takes you from zero to interview-ready Application Security Engineer with a cloud focus. Every post includes real code, real tools, and real attack scenarios.

Full Series Roadmap:

1. Introduction — Mindset, CIA Triad and Threat Landscape ← you are here
2. Secure Coding Fundamentals — Input Validation, Output Encoding, Error Handling
3. OWASP Top 10 Deep Dive — Every Vulnerability With Code
4. Authentication & Authorization — OAuth 2.0, JWT, Session Security
5. Cryptography for AppSec Engineers — Hashing, Encryption, TLS
6. API Security — REST, GraphQL and gRPC Attack Surfaces
7. Cloud Security Fundamentals — AWS Shared Responsibility and IAM
8. AWS Security Deep Dive — KMS, CloudTrail, GuardDuty, Security Hub
9. Container Security — Docker and Kubernetes Hardening
10. Infrastructure as Code Security — Terraform and CloudFormation Scanning
11. SAST — Static Application Security Testing
12. DAST — Dynamic Application Security Testing
13. Software Composition Analysis — Dependencies and Supply Chain
14. Secrets Management — Vault, AWS Secrets Manager, Zero Hardcoded Secrets
15. DevSecOps — Security in CI/CD Pipelines
16. Threat Modeling — STRIDE, PASTA and Attack Trees
17. Penetration Testing Methodology — Recon to Report
18. Security Monitoring and Incident Response
19. Compliance and Governance — SOC 2, PCI-DSS, GDPR
20. Cloud-Native Security Patterns — Zero Trust, Defense in Depth

Why Application Security Matters

Every week brings headlines about breached databases, stolen credentials, and ransomware shutting down hospitals. The root cause in the majority of breaches is not sophisticated zero-days — it is preventable application-layer vulnerabilities:

2023 Breach Statistics:
├── 74% involved the human element (phishing, misuse, error)
├── 49% caused by credential theft
├── 83% executed by external actors
└── Average cost: $4.45 million per breach (IBM 2023)

Application Security Engineers prevent this. You sit at the intersection of development, operations, and security — reviewing code, designing secure architectures, running security tests, and building security into the software delivery pipeline.

The Security Mindset

Normal engineers ask: "Does this feature work?"

Security engineers ask: "How can this feature be abused?"

This is the most important shift. For every piece of code you read or write, ask:

SECURITY REVIEW QUESTIONS FOR ANY FEATURE:
├── What data does this handle? How sensitive?
├── Who can call this? Is it authenticated?
├── What happens with unexpected/malicious input?
├── What does failure look like? Does it fail open or closed?
├── What does this log? Could logs contain sensitive data?
├── What trust assumptions does this make?
└── If an attacker controlled this input, what could they do?

Example — thinking like an attacker:

A developer writes a search endpoint:

# Developer thinks: "Search for products by name"
@app.route('/search')
def search():
    query = request.args.get('q')
    results = db.execute(f"SELECT * FROM products WHERE name LIKE '%{query}%'")
    return jsonify(results)

A security engineer thinks:

• What if query is '; DROP TABLE products; --? → SQL injection
• What if query is <script>alert(1)</script>? → XSS in results
• What if query is ../../../../etc/passwd? → Path traversal (if file-based)
• What if query is AAAA... (10MB)? → DoS via resource exhaustion
• Is there rate limiting? → Brute force / enumeration

The developer saw a feature. The security engineer sees an attack surface.

The CIA Triad

Every security decision maps back to one of three properties:

┌─────────────────────────────────────────────────────────┐
│                    CIA TRIAD                            │
│                                                         │
│    Confidentiality    Integrity       Availability      │
│    ───────────────    ─────────────   ────────────      │
│    Data is only       Data is         System is         │
│    accessible to      accurate and    accessible        │
│    authorised         unmodified      when needed       │
│    parties            in transit                        │
│                       and storage                       │
│                                                         │
│    Attack: Data       Attack:         Attack:           │
│    theft,             Tampering,      DDoS,             │
│    credential leak    MitM,           ransomware        │
│                       SQL injection                     │
└─────────────────────────────────────────────────────────┘

Confidentiality violations:

# ❌ Password stored in plaintext — confidentiality violation
user.password = request.form['password']  # never do this

# ❌ Sensitive data in logs
logger.info(f"User logged in: {username}, password: {password}")  # never log passwords

# ❌ Credit card in URL
GET /checkout?card=4111111111111111&cvv=123  # URLs are logged everywhere

Integrity violations:

# ❌ JWT without signature verification — anyone can forge tokens
token = jwt.decode(token, options={"verify_signature": False})

# ❌ Price set by client — integrity violation
order_total = request.json['total']  # attacker sends $0.01 for a $1000 order

Availability violations:

# ❌ No rate limiting — DoS via resource exhaustion
@app.route('/send-email')
def send_email():
    # Attacker calls this 10,000 times, exhausting your email quota
    send_email(request.json['to'], request.json['body'])

Attack Surface Analysis

The attack surface is everything an attacker can reach and interact with. Your first job as an AppSec engineer on any new project is mapping it.

APPLICATION ATTACK SURFACE MAP:
│
├── Network Layer
│   ├── Open ports (scan with nmap)
│   ├── TLS version and cipher suites
│   └── Network segmentation gaps
│
├── Application Layer
│   ├── Every HTTP endpoint (GET, POST, PUT, DELETE)
│   ├── Every form input and file upload
│   ├── Every query parameter and header
│   ├── Authentication endpoints (/login, /register, /forgot-password)
│   ├── Admin endpoints (/admin/*)
│   └── Internal service calls (microservices)
│
├── Data Layer
│   ├── Database queries (SQL injection surface)
│   ├── File system access
│   ├── External API calls
│   └── Cache access (Redis, Memcached)
│
├── Third-Party Components
│   ├── npm/pip/maven dependencies
│   ├── Docker base images
│   └── Cloud services (S3, SQS, RDS)
│
└── Human Layer
    ├── Phishing surface (company emails)
    ├── Social engineering
    └── Insider threats

Tool to map HTTP endpoints:

# Crawl a web app to find all endpoints
pip install scrapy

# Or use OWASP ZAP spider
docker run -v $(pwd):/zap/wrk/:rw owasp/zap2docker-stable \
  zap-baseline.py -t https://your-app.com -r report.html

# Find hidden endpoints
ffuf -w /usr/share/wordlists/dirb/common.txt \
     -u https://your-app.com/FUZZ \
     -mc 200,301,302,403

The OWASP Top 10 — Quick Overview

The Open Web Application Security Project publishes the Top 10 most critical risks. You must know all 10 cold:

OWASP Top 10 (2021):
│
├── A01 Broken Access Control        ← #1, was #5 in 2017
│   └── Users accessing other users' data
│
├── A02 Cryptographic Failures       ← was "Sensitive Data Exposure"
│   └── Weak encryption, plaintext passwords, expired certs
│
├── A03 Injection                    ← was #1 for years
│   └── SQL, NoSQL, OS command, LDAP injection
│
├── A04 Insecure Design              ← NEW in 2021
│   └── Security not considered in architecture
│
├── A05 Security Misconfiguration    ← grew from #6
│   └── Default passwords, open cloud storage, verbose errors
│
├── A06 Vulnerable Components        ← was "Using Components with Known Vulnerabilities"
│   └── Outdated dependencies with CVEs
│
├── A07 Identification & Auth Failures ← was "Broken Authentication"
│   └── Weak passwords, no MFA, broken session management
│
├── A08 Software & Data Integrity    ← NEW in 2021
│   └── CI/CD pipeline compromise, unsigned updates
│
├── A09 Security Logging & Monitoring Failures ← was #10
│   └── Not detecting breaches, no audit trail
│
└── A10 SSRF                         ← NEW in 2021
    └── Server-Side Request Forgery — server fetches attacker-controlled URLs

We cover every one of these in depth in Part 3.

Security Vocabulary You Must Know

Build this vocabulary — every concept appears in interviews and real work:

Your Learning Path and Tools to Install

Set up your security lab now — you'll use these throughout the series:

# 1. OWASP ZAP (dynamic scanner)
docker pull owasp/zap2docker-stable

# 2. Burp Suite Community Edition
# Download from portswigger.net/burp/communitydownload

# 3. nikto (web server scanner)
apt-get install nikto

# 4. nmap (network scanner)
apt-get install nmap

# 5. Semgrep (SAST)
pip install semgrep

# 6. Trivy (container/dependency scanner)
brew install aquasecurity/trivy/trivy
# or
apt-get install trivy

# 7. tfsec (Terraform security scanner)
brew install tfsec

# 8. truffleHog (secret scanner)
pip install truffleHog

# 9. OWASP Dependency-Check
# Download from jeremylong.github.io/DependencyCheck/

# 10. Vulnerable practice apps
docker pull webgoat/webgoat          # OWASP WebGoat
docker pull bkimminich/juice-shop    # OWASP Juice Shop
docker pull raesene/bwapp            # bWAPP

Start the practice apps:

# OWASP Juice Shop — modern vulnerable app (React + Node.js)
docker run -p 3000:3000 bkimminich/juice-shop
# Open: http://localhost:3000

# OWASP WebGoat — Java-based training app
docker run -p 8080:8080 webgoat/webgoat
# Open: http://localhost:8080/WebGoat

These are intentionally vulnerable applications — never run on a public server.

How This Series Is Structured

Each post follows this pattern:

1. CONCEPT     — What is it and why does it matter?
2. ATTACK      — How do attackers exploit it? (with real examples)
3. DEFENCE     — How do you prevent it? (with code)
4. DETECTION   — How do you find it in existing code/systems?
5. TOOLS       — What tools automate detection?
6. INTERVIEW   — Questions you'll be asked and model answers

By the end you will be able to:

• Review code for security vulnerabilities
• Design secure cloud architectures on AWS/Azure/GCP
• Build security into CI/CD pipelines
• Perform basic penetration testing
• Respond to security incidents
• Explain every OWASP Top 10 vulnerability with a code example
• Pass application security engineer technical interviews

What's Next

In Part 2 we write secure code — input validation, output encoding, error handling, logging hygiene, and the 10 fundamental rules every developer must follow before a line of code ships to production.