Web Application Security Fundamentals #02: Tujuan Utama Web Security

Security requirement sering ditulis terlalu abstrak: “sistem harus aman”, “data harus terlindungi”, atau “gunakan encryption”. Kalimat semacam itu terdengar benar, tetapi tidak menjelaskan asset, skenario ancaman, control, maupun cara membuktikannya.

Tutorial ini memakai Confidentiality, Integrity, Availability, dan Authenticity sebagai alat berpikir. Empat tujuan tersebut tidak otomatis menjadi control. Kita harus menerjemahkannya menjadi requirement yang spesifik, terukur, dan dapat diuji.

Batas praktik: contoh hanya untuk local lab, aplikasi milik sendiri, atau sistem yang telah memberi izin tertulis.

Tujuan pembelajaran

Setelah mengikuti tutorial, Anda dapat:

• membedakan Confidentiality, Integrity, Availability, dan Authenticity;
• mengenali konflik dan trade-off antar-tujuan;
• menulis security requirement yang testable;
• memilih evidence yang tepat;
• menghindari penggunaan encryption sebagai jawaban universal.

Prasyarat

Pahami konsep asset, threat, vulnerability, risk, authentication, dan authorization dari artikel pertama. Siapkan satu contoh aplikasi—misalnya portal siswa, toko online, atau internal dashboard—untuk latihan.

1. Tentukan asset dan business impact

Mulailah dari asset, bukan technology. Pada portal siswa, asset dapat meliputi:

• identity siswa dan wali;
• nilai serta catatan akademik;
• credential pengguna;
• dokumen;
• audit trail perubahan;
• availability layanan saat ujian atau pendaftaran.

Untuk setiap asset, tanyakan dampak jika:

1. dibaca pihak yang tidak berhak;
2. diubah tanpa izin;
3. tidak tersedia saat dibutuhkan;
4. sumber atau identitasnya dipalsukan.

Hasilnya akan berbeda. Kebocoran jadwal publik mungkin kecil, sedangkan perubahan nilai atau pengambilalihan account berdampak besar.

2. Confidentiality: siapa boleh membaca apa?

Confidentiality membatasi disclosure kepada pihak yang berwenang. Encryption penting, tetapi bukan satu-satunya control. Data dapat dienkripsi di storage namun tetap bocor karena Broken Access Control pada API.

Contoh requirement yang terlalu kabur:

Data siswa harus rahasia.

Versi yang dapat diuji:

Endpoint detail siswa hanya mengembalikan record milik siswa terautentikasi atau pengguna dengan role yang secara eksplisit diberi permission. Setiap penolakan menghasilkan status yang sesuai tanpa membocorkan isi record.

Test case ilustratif:

\\\`javascript it("menolak siswa membaca record milik siswa lain", async () => { const tokenA = await loginAsStudent("student-a"); const response = await api.get("/students/student-b") .set("Authorization", \Bearer \${tokenA}\);

expect([403, 404]).toContain(response.status); expect(response.body).not.toHaveProperty("nationalId"); }); \\\`

Status \403\ atau \404\ harus dipilih konsisten sesuai threat model. \404\ dapat mengurangi object enumeration, tetapi bukan pengganti authorization.

Control confidentiality antara lain:

• server-side authorization;
• least privilege;
• encryption in transit dan at rest;
• data minimization;
• secure session;
• masking pada UI dan log;
• retention policy;
• secret management.

3. Integrity: siapa boleh mengubah dan bagaimana perubahan dibuktikan?

Integrity memastikan data dan proses tidak berubah secara tidak sah atau tidak terdeteksi. Ini bukan hanya checksum file. Pada aplikasi bisnis, integrity juga mencakup state transition, approval, amount, dan audit trail.

Requirement yang lebih baik:

Perubahan nilai hanya dapat dilakukan guru yang memiliki assignment aktif pada kelas tersebut. Perubahan menyimpan actor, waktu, nilai sebelum dan sesudah, serta correlation ID. Audit record tidak dapat diedit melalui application role biasa.

Contoh optimistic concurrency:

\\\`http GET /api/profile ETag: "profile-v17"

PUT /api/profile If-Match: "profile-v17" Content-Type: application/json \\\`

Jika record telah berubah, server dapat menolak update lama dengan \412 Precondition Failed\. Mekanisme ini membantu mencegah lost update, tetapi authorization tetap harus diperiksa.

Control integrity dapat berupa:

• authorization pada write operation;
• parameterized query;
• validation terhadap business invariant;
• transaction;
• digital signature atau MAC untuk kasus yang tepat;
• immutable atau append-only audit trail;
• versioning dan concurrency control;
• review/approval untuk perubahan kritis.

Hash tanpa key tidak membuktikan siapa pembuat data. Untuk authenticity dan tamper detection terhadap penyerang yang dapat mengganti data sekaligus hash, gunakan mekanisme cryptographic yang sesuai dan key management yang benar.

4. Availability: layanan tersedia dalam kondisi normal dan gagal

Availability bukan hanya uptime dashboard. Aplikasi mungkin mengembalikan HTTP 200 tetapi dependency lambat, queue menumpuk, atau fitur kritis tidak berfungsi.

Requirement yang testable perlu menyebut layanan, target, periode, dan kondisi. Contoh:

Endpoint autentikasi memiliki timeout ke identity provider, menerapkan bounded retry dengan backoff, dan gagal secara tertutup. Kegagalan dependency menghasilkan response terkontrol tanpa membocorkan stack trace.

Untuk availability, perhatikan:

• capacity dan performance budget;
• timeout;
• bounded retry dan backoff;
• circuit breaker;
• rate limiting;
• redundancy;
• health check yang bermakna;
• backup dan restore test;
• disaster recovery;
• protection terhadap resource exhaustion;
• monitoring dan alerting.

Retry yang tidak dibatasi dapat memperburuk outage menjadi retry storm. Availability control harus diuji pada exceptional condition, bukan hanya happy path.

5. Authenticity: apakah identitas dan sumber dapat dipercaya?

Authenticity menjawab apakah user, service, atau pesan benar berasal dari pihak yang diklaim. Password hanyalah salah satu authenticator.

Pada web application, authenticity dapat melibatkan:

• authentication pengguna;
• MFA;
• server certificate dalam TLS;
• workload identity antar-service;
• signed webhook;
• email domain control;
• session binding dan rotation;
• anti-phishing control.

Contoh verifikasi webhook secara konseptual:

\\\`javascript function verifyWebhook(rawBody, receivedSignature, secret) { const expected = hmacSha256(secret, rawBody); return constantTimeEqual(expected, receivedSignature); } \\\`

Implementasi production harus mengikuti dokumentasi provider, termasuk exact canonicalization, timestamp, replay window, algorithm, dan encoding. Jangan menyalin pseudocode menjadi production code tanpa library yang tepat.

Authentication berbeda dari authorization. Account yang berhasil login belum tentu boleh mengakses seluruh data.

6. Tambahkan accountability tanpa mencampur konsep

Accountability membantu menghubungkan tindakan dengan actor dan evidence. Ia biasanya dibangun lewat identity, audit trail, time synchronization, log integrity, separation of duties, dan retention.

Jangan mencatat secret. Contoh event yang lebih aman:

\\\`json { "event": "student.grade.updated", "actor_id": "usr_8f3...", "target_id": "grade_91a...", "result": "success", "correlation_id": "req_b72...", "timestamp": "2026-08-22T10:15:30Z" } \\\`

Hindari password, session token, full authorization header, dan personal data yang tidak diperlukan.

7. Kenali trade-off

Security goals dapat saling memengaruhi:

• encryption meningkatkan confidentiality tetapi key loss dapat merusak availability;
• audit logging meningkatkan accountability tetapi excessive logging dapat membocorkan data;
• aggressive rate limiting membantu availability terhadap abuse tetapi dapat memblokir pengguna sah;
• fail-open menjaga fungsi tersedia tetapi dapat merusak confidentiality atau integrity;
• fail-closed melindungi akses tetapi dapat menurunkan availability.

Tidak ada jawaban universal. Keputusan harus berdasarkan asset, threat model, business impact, dan recovery capability.

8. Tulis requirement dengan pola yang konsisten

Gunakan pola:

\\\`text Dalam kondisi [konteks], sistem harus [perilaku/control], untuk melindungi [asset] dari [threat], dan dibuktikan melalui [test/evidence]. \\\`

Contoh:

Saat pengguna mengganti password, sistem harus mencabut session aktif lain dan mencatat security event tanpa menyimpan credential, untuk mengurangi risiko persistence setelah account compromise. Perilaku dibuktikan melalui integration test dan audit log review.

Requirement tersebut lebih berguna daripada “gunakan session yang aman”.

9. Buat verification matrix

Matrix membantu tim menghindari control yang tidak terkait dengan risiko.

10. Jalankan negative test

Positive test memastikan pengguna sah dapat bekerja. Security juga memerlukan negative test:

• user tanpa login;
• user dengan role salah;
• object milik user lain;
• token expired;
• signature salah;
• timestamp lama;
• input di luar range;
• dependency timeout;
• duplicate request;
• concurrent update.

Catat expected behavior. “Tidak crash” belum cukup; sistem harus menolak dengan aman, tidak membocorkan data, dan menghasilkan telemetry yang sesuai.

Kesalahan yang sering terjadi

Mengenkripsi semuanya tanpa threat model

Encryption memerlukan key lifecycle: generation, distribution, storage, rotation, revocation, backup, dan recovery. Salah mengelola key dapat menghilangkan availability tanpa benar-benar meningkatkan confidentiality.

Menyebut backup tanpa restore test

Backup yang belum pernah dipulihkan adalah harapan, bukan control yang terbukti.

Menganggap audit log otomatis tepercaya

Jika actor yang diaudit dapat menghapus log dengan permission yang sama, integrity evidence lemah. Terapkan separation of duties dan pengiriman log ke storage yang lebih terlindungi.

Memakai role sebagai satu-satunya konteks

Authorization sering membutuhkan ownership, tenant, relationship, location, transaction state, dan waktu—tidak hanya role.

Checklist

• [ ] Asset dan owner sudah ditentukan.
• [ ] Confidentiality requirement menyebut subject, object, dan action.
• [ ] Integrity mencakup business rule dan auditability.
• [ ] Availability diuji saat dependency gagal.
• [ ] Authenticity tidak disamakan dengan authorization.
• [ ] Log tidak menyimpan secret.
• [ ] Trade-off dicatat.
• [ ] Setiap requirement memiliki evidence.

Kesimpulan

Confidentiality, Integrity, Availability, dan Authenticity berguna jika diterjemahkan menjadi perilaku yang dapat diuji. Mulailah dari asset dan threat scenario, pilih control yang relevan, lalu tentukan evidence. Security akhirnya menjadi bagian dari engineering, bukan kalimat dekoratif pada dokumen requirement.

Tutorial berikutnya membedah arsitektur web modern dan aliran request–response agar kita tahu di mana trust boundary dan security control benar-benar bekerja.

Referensi resmi

• OWASP Top 10:2025 — diakses 22 Agustus 2026.
• OWASP Authentication Cheat Sheet — diakses 22 Agustus 2026.
• OWASP Session Management Cheat Sheet — diakses 22 Agustus 2026.
• OWASP Logging Cheat Sheet — diakses 22 Agustus 2026.
• OWASP Transport Layer Security Cheat Sheet — diakses 22 Agustus 2026.