Web Application Security Fundamentals #04: Mengenal OWASP Top 10:2025 dan Risk Assessment

OWASP Top 10 adalah awareness document, bukan standar sertifikasi atau checklist kelulusan. Dokumen ini merangkum 10 kategori risiko paling umum di web application berdasarkan data real-world. Pemahaman yang tepat tentang Top 10 membantu Anda:

1. Mengidentifikasi mana risiko paling penting untuk aplikasi Anda
2. Mengalokasikan resources security dengan bijak
3. Memetakan findings ke actionable engineering tasks
4. Berkomunikasi risiko ke stakeholders

Etika dan Scope: Gunakan Top 10 sebagai awareness framework. Tidak boleh digunakan untuk memvalidasi "aman" tanpa threat modeling lokal dan testing menyeluruh.

Tujuan Pembelajaran

Setelah modul ini, Anda dapat:

• Menyebutkan 10 kategori OWASP Top 10:2025 dengan benar
• Membedakan antara categoria dengan CWE (Common Weakness Enumeration)
• Memahami perubahan signifikan dari Top 10:2021
• Mapping Top 10 categories ke actionable engineering requirements
• Menggunakan Top 10 sebagai starting point untuk threat modeling, bukan sebagai checklist
• Membedakan OWASP Top 10 vs ASVS vs WSTG

1. OWASP Top 10:2025 — 10 Kategori Risiko

Perubahan dari Top 10:2021

Baru di 2025:

• A10 SSRF — Previously in A06, now standalone (growing threat)

Hilang/Merged:

• Insecure XML External Entity (XXE) → Merged ke A04 (Cryptographic Failures)
• Using Components with Known Vulnerabilities → Merged ke A03

Reordered: Ranking berubah berdasarkan data terbaru dari berbagai sumber.

2. Detailed Deep-Dive: 3 Kategori Tertinggi

A01: Broken Access Control

Definisi: Authorization logic tidak bekerja dengan benar. Authenticated user dapat mengakses resource milik orang lain atau melakukan action yang tidak diizinkan.

Contoh Vulnerabilities:

• Object-level authorization flawed → Ubah resource ID, akses punya orang lain
• User can promote self to admin → Ubah role di request
• Horizontal privilege escalation → User A akses user B's data
• Vertical privilege escalation → Regular user perform admin action

Code Example (Vulnerable):

# ❌ VULNERABLE
@app.route('/api/users/<user_id>/profile', methods=['GET'])
def get_user_profile(user_id):
    user = User.query.filter_by(id=user_id).first()
    return jsonify(user.to_dict())  # No ownership check!

# Attacker:
# GET /api/users/999/profile
# Access any user's profile

Remediation:

# ✅ SECURE
@app.route('/api/users/<user_id>/profile', methods=['GET'])
@login_required
def get_user_profile(user_id):
    # Verify resource ownership
    if int(user_id) != current_user.id and not current_user.is_admin:
        return jsonify({'error': 'Unauthorized'}), 403
    
    user = User.query.filter_by(id=user_id).first()
    if not user:
        return jsonify({'error': 'Not found'}), 404
    
    return jsonify(user.to_dict())

Testing:

# Test 1: Access own profile
curl -H "Authorization: Bearer $TOKEN_USER_1" \
  https://api.example.com/users/1/profile
# Should return 200

# Test 2: Try access other user's profile
curl -H "Authorization: Bearer $TOKEN_USER_1" \
  https://api.example.com/users/2/profile
# Should return 403

A02: Security Misconfiguration

Definisi: Default credentials, exposed config, unnecessary services, atau security-relevant settings yang tidak dikonfigurasi dengan tepat.

Contoh:

• Default admin credentials not changed
• Unnecessary HTTP methods enabled (PUT, DELETE di public API)
• Stack traces visible di error pages
• X-Powered-By header reveals technology
• CORS misconfigured (Access-Control-Allow-Origin: * dengan credentials)
• Debug mode enabled di production
• Unnecessary services running (admin panel exposed)

Remediation Checklist:

# Remove unnecessary HTTP methods
curl -X PUT https://api.example.com/users/1
# Should return 405 Method Not Allowed (if not needed)

# Check for exposed files
curl https://api.example.com/config/database.php
curl https://api.example.com/admin/
# Should return 404 atau 403 (not 200 with credentials)

# Headers hardening
curl -I https://api.example.com
# ✅ Harus ada: HSTS, CSP, X-Frame-Options
# ❌ Jangan ada: Server version, X-Powered-By (revelatory)

# Check for debug mode
curl https://api.example.com/invalid-endpoint
# Should return generic 404, bukan detailed error + stack trace

A05: Injection

Definisi: Untrusted input dimasukkan ke interpreter (SQL, NoSQL, OS command, template engine) tanpa proper sanitization.

SQL Injection Example:

# ❌ VULNERABLE
user_email = request.args.get('email')
query = f"SELECT * FROM users WHERE email = '{user_email}'"
result = db.execute(query)

# Attacker: email = ' OR '1'='1
# Query becomes: SELECT * FROM users WHERE email = '' OR '1'='1'
# Returns all users!

# ✅ SAFE - Parameterized query
query = "SELECT * FROM users WHERE email = ?"
result = db.execute(query, (user_email,))

Testing:

curl "https://api.example.com/search?q=test' OR '1'='1"
# Should escape quotes, not return all records

A07: Authentication Failures

Definisi: Login mechanism, session management, atau password recovery tidak aman.

Examples:

• Weak password policy
• No rate limiting on login attempts (brute force)
• Session ID not rotated after login
• Credentials in URL (https://app.com?username=user&password=pass)
• MFA bypass atau recovery flow weak
• Concurrent session limits missing

Remediation:

// Rate limiting
const loginLimiter = rateLimit({
  windowMs: 15 * 60 * 1000,  // 15 min
  max: 5,                     // 5 attempts
  skipSuccessfulRequests: true
});

app.post('/login', loginLimiter, async (req, res) => {
  const user = await User.findByEmail(req.body.email);
  if (!user || !user.verifyPassword(req.body.password)) {
    return res.status(401).json({ error: 'Invalid credentials' });
  }
  
  // Rotate session
  req.session.regenerate(() => {
    req.session.userId = user.id;
    res.json({ success: true });
  });
});

3. Perbedaan: Top 10 vs ASVS vs WSTG

Contoh usage:

1. Management: Lihat Top 10 → Understand risks
2. Architect: Gunakan ASVS → Design secure application
3. Developer: Ikuti ASVS requirements → Implement secure coding
4. Tester: Gunakan WSTG → Test setiap requirement

4. Mapping Top 10 ke Engineering Tasks

Gunakan pola berikut untuk convert category menjadi actionable task:

Step 1: Pick category

A01: Broken Access Control

Step 2: Describe risk untuk aplikasi Anda

Risk: Authenticated user dapat akses/modify invoice milik orang lain
       dengan mengubah invoice ID di URL.
Threat Actor: Disgruntled employee
Likelihood: High (easy to exploit)
Impact: High (financial fraud, data breach)

Step 3: Map ke requirement (dari ASVS)

ASVS V4.1.1: Verify that the application enforces access control 
at every tier of the application (backend, API, frontend).

ASVS V4.1.2: Verify that the application enforces authorization 
decisions at every tier.

Step 4: Tulis test case

TEST-A01-001 (Happy path):
  As admin
  GET /api/invoices/123 (milik user A)
  Expect: 200 OK

TEST-A01-002 (Negative path - different user):
  As user A
  GET /api/invoices/999 (milik user B)
  Expect: 403 Forbidden
  Log harus capture attempt ini
  
TEST-A01-003 (Privilege escalation):
  As regular user
  POST /api/users/1 with role=admin
  Expect: 403 Forbidden atau role ignored

Step 5: Assign owner, due date, track progress

Owner: Backend Team Lead
Due Date: 2 sprints
Priority: Critical
Status: In Progress
Evidence: Pull request #542, test coverage 95%

5. Risk-Based Prioritization

Tidak semua Top 10 category punya priority sama untuk aplikasi Anda.

Scoring Framework:

Risk Score = (Likelihood × Impact) + Exploitability

Critical:  Score ≥ 8
High:      6 ≤ Score < 8
Medium:    4 ≤ Score < 6
Low:       Score < 4

Contoh: E-commerce Application

Contoh: Internal HR Application

Key insight: Priority berbeda per aplikasi! Jangan copy-paste Top 10 ranking.

6. OWASP Top 10 Checklist

• [ ] Saya bisa menyebutkan 10 kategori tanpa lihat daftar
• [ ] Saya tahu perubahan dari 2021 ke 2025
• [ ] Saya understand A01 (Broken Access Control) dengan contoh dari aplikasi saya
• [ ] Saya bisa mapping category ke ASVS requirements
• [ ] Saya tahu Top 10 bukan = "comprehensive security checklist"
• [ ] Saya sudah lakukan risk scoring untuk aplikasi saya
• [ ] Saya punya threat scenarios untuk top 3 risk di aplikasi saya

Kesalahan Umum

❌ "Kami comply dengan Top 10" Top 10 bukan compliance framework. Gunakan OWASP ASVS untuk compliance-level requirements.

❌ "Scanner pass = kami compliant dengan Top 10" Scanner hanya detect known patterns. Insecure Design, business logic, dan edge cases tetap perlu manual testing.

❌ "Top 10:2025 lebih akurat dari 2021 jadi 2021 sudah deprecated" Vulnerabilities dari 2021 masih ada di 2025. Perubahan reflect data terbaru, bukan replacemen.

Kesimpulan

OWASP Top 10:2025 adalah starting point untuk web application risk identification, bukan finish line untuk security.

Gunakan Top 10 untuk:

1. Understand common risks di industri
2. Communicate dengan non-technical stakeholders
3. Starting point untuk threat modeling
4. Reference untuk security training

Jangan gunakan Top 10 untuk:

1. Memvalidasi aplikasi adalah "aman"
2. Skip threat modeling atau security review lokal
3. Replace testing methodology (gunakan WSTG)

Modul berikutnya (#05) membahas attack vectors dan bagaimana vulnerability di-exploit secara praktis.

Referensi

• OWASP Top 10:2025
• OWASP Application Security Verification Standard (ASVS)
• OWASP Web Security Testing Guide (WSTG)
• CWE Top 25

Baca Berikutnya: #05 - Common Web Attack Vectors - SQL Injection, XSS, CSRF