Membangun aplikasi web hari ini tidak cukup hanya memastikan aplikasi berjalan dengan baik. Aplikasi juga harus dirancang agar mampu menghadapi kesalahan konfigurasi, kebocoran data, pencurian akun, eksploitasi API, hingga serangan terhadap dependency yang digunakan.

Semakin banyak layanan yang berpindah ke web dan API, semakin besar pula attack surface yang harus dilindungi.

Karena itu, keamanan sebaiknya tidak ditempatkan sebagai pekerjaan tambahan setelah aplikasi selesai dibuat.

Security is not a feature. Security is part of the architecture.

Salah satu referensi yang paling banyak digunakan untuk membantu developer membangun aplikasi yang lebih aman adalah OWASP (Open Worldwide Application Security Project).

Artikel ini membahas konsep dasar web security, proteksi yang sebaiknya diterapkan, serta bagaimana OWASP dapat digunakan sebagai standar praktis dalam proses pengembangan software.

Apa Itu Web Security?

Web security adalah serangkaian metode, teknologi, proses, dan kebijakan untuk melindungi aplikasi web, API, server, database, dan data pengguna dari akses maupun aktivitas yang tidak sah.

Sebuah aplikasi web biasanya memiliki banyak komponen:

User
  │
  ▼
Browser / Mobile App
  │
  ▼
Internet
  │
  ▼
CDN / WAF / Reverse Proxy
  │
  ▼
Web Server
  │
  ▼
Application / API
  │
  ├────────► Cache
  │
  ├────────► External API
  │
  └────────► Database

Setiap komponen tersebut dapat menjadi titik serangan.

Contohnya, aplikasi memiliki validasi input yang baik, tetapi database dapat diakses langsung dari internet. Atau server sudah diamankan, tetapi API tidak melakukan pemeriksaan otorisasi dengan benar.

Keamanan aplikasi harus dilihat sebagai satu kesatuan sistem, bukan hanya keamanan source code.

Mengenal OWASP

OWASP atau Open Worldwide Application Security Project adalah organisasi nonprofit yang menyediakan berbagai referensi terbuka mengenai keamanan aplikasi.

Salah satu proyek OWASP yang paling dikenal adalah:

OWASP Top 10

OWASP Top 10 berisi kategori risiko keamanan aplikasi web yang perlu menjadi perhatian developer dan organisasi.

Namun OWASP sebenarnya jauh lebih luas daripada Top 10.

Beberapa referensi penting lainnya antara lain:

• OWASP Application Security Verification Standard (ASVS)
• OWASP Web Security Testing Guide (WSTG)
• OWASP Cheat Sheet Series
• OWASP API Security Top 10
• OWASP Software Assurance Maturity Model (SAMM)

Jika OWASP Top 10 memberikan gambaran mengenai risiko, ASVS dapat digunakan sebagai referensi requirement dan verification, sedangkan WSTG membantu dalam proses security testing.

OWASP Top 10

OWASP Top 10 membantu developer memahami kategori kelemahan keamanan yang umum dan berdampak besar.

Beberapa konsep yang perlu diperhatikan dalam pengembangan aplikasi modern antara lain:

1. Broken Access Control

Masalah terjadi ketika pengguna dapat mengakses resource atau menjalankan fungsi yang seharusnya tidak menjadi haknya.

Misalnya tersedia endpoint:

GET /api/invoice/1001

User mengganti ID menjadi:

GET /api/invoice/1002

Jika aplikasi hanya mengecek apakah user sudah login tanpa memastikan bahwa invoice 1002 memang miliknya, maka terjadi masalah access control.

Validasi tidak boleh hanya:

Apakah user login?

Tetapi juga:

Apakah user memiliki hak terhadap resource ini?

Prinsip yang dapat digunakan adalah:

Deny by default.

Akses diberikan hanya ketika terdapat aturan yang secara eksplisit mengizinkannya.

2. Security Misconfiguration

Aplikasi yang source code-nya relatif aman tetap dapat diretas karena konfigurasi yang buruk.

Contohnya:

Database Port
5432
    │
    ▼
PUBLIC INTERNET

Padahal seharusnya:

Internet
   │
   ▼
Firewall / WAF
   │
   ▼
Application Server
   │
   ▼
Private Network
   │
   ▼
Database

Beberapa contoh security misconfiguration:

• database terbuka ke internet,
• default username/password tidak diganti,
• debug mode aktif di production,
• directory listing aktif,
• error menampilkan stack trace,
• permission terlalu luas,
• service yang tidak diperlukan tetap aktif.

Konfigurasi server merupakan bagian dari keamanan aplikasi.

3. Software Supply Chain Failures

Aplikasi modern sangat bergantung pada library dan dependency.

Contohnya aplikasi Java:

Spring Boot Application
        │
        ├── Spring Framework
        ├── Hibernate
        ├── Jackson
        ├── Apache Commons
        └── Library lainnya

Kita mungkin hanya menulis sebagian source code aplikasi, tetapi aplikasi sebenarnya menjalankan banyak kode yang berasal dari dependency.

Karena itu dependency harus diperlakukan sebagai bagian dari attack surface.

Developer perlu:

• melakukan dependency scanning,
• memonitor CVE,
• melakukan upgrade dependency,
• menghapus library yang tidak digunakan,
• menggunakan repository terpercaya,
• menjaga dependency lock/version,
• menghasilkan SBOM jika diperlukan.

4. Cryptographic Failures

Data sensitif harus dilindungi baik ketika disimpan maupun ketika dikirimkan.

Contoh sederhana:

Browser
   │
   │ HTTPS / TLS
   ▼
Application
   │
   ▼
Database

Password tidak boleh disimpan seperti:

username | password
-------------------
sena     | password123

Password harus diproses menggunakan algoritma password hashing yang sesuai seperti:

Argon2
bcrypt
PBKDF2

Password hashing berbeda dengan encryption.

Password umumnya tidak perlu dapat dikembalikan menjadi plaintext.

5. Injection

Injection terjadi ketika input pengguna diperlakukan sebagai bagian dari perintah.

Salah satu contoh klasik adalah SQL Injection.

Kode yang berbahaya:

String sql =
    "SELECT * FROM users WHERE username = '" +
    username + "'";

Input attacker dapat mengubah struktur query.

Pendekatan yang lebih aman adalah menggunakan parameterized query:

PreparedStatement ps =
    connection.prepareStatement(
        "SELECT * FROM users WHERE username = ?"
    );

ps.setString(1, username);

Framework ORM seperti Hibernate/JPA dapat membantu, tetapi developer tetap harus berhati-hati terhadap query dinamis atau native query yang dibangun melalui string concatenation.

Injection juga tidak terbatas pada SQL.

Ada pula:

Command Injection
LDAP Injection
NoSQL Injection
Template Injection
XPath Injection

6. Insecure Design

Tidak semua masalah keamanan berasal dari kesalahan coding.

Kadang desain sistemnya sendiri sudah memiliki kelemahan.

Contohnya sistem reset password:

User
 │
 ▼
Forgot Password
 │
 ▼
Masukkan Email
 │
 ▼
Reset Password

Tetapi sistem tidak memiliki:

Rate Limiting
Token Expiration
One-Time Token
Audit Log
Notification
Anti Enumeration

Walaupun source code tidak memiliki SQL Injection atau XSS, proses tersebut tetap dapat memiliki risiko keamanan.

Karena itu security harus dimulai sejak fase desain.

7. Identification and Authentication Failures

Authentication menjawab:

Siapa Anda?

Authorization menjawab:

Apa yang boleh Anda lakukan?

Keduanya berbeda.

Contoh alur:

Username + Password
        │
        ▼
Authentication
        │
        ▼
MFA
        │
        ▼
Session / Token
        │
        ▼
Authorization

Beberapa proteksi authentication:

• password policy,
• MFA,
• rate limiting,
• session timeout,
• secure cookie,
• token expiration,
• account lockout yang dirancang dengan baik,
• monitoring login abnormal.

8. Software or Data Integrity Failures

Aplikasi harus memastikan software, update, konfigurasi, maupun data yang digunakan berasal dari sumber yang dapat dipercaya dan tidak dimodifikasi secara tidak sah.

Contohnya pipeline:

Developer
    │
    ▼
Git Repository
    │
    ▼
CI/CD
    │
    ▼
Build Artifact
    │
    ▼
Production

Jika pipeline tersebut dapat dimanipulasi, attacker tidak harus menyerang aplikasi secara langsung.

Attacker cukup memasukkan kode berbahaya ke proses deployment.

Proteksi dapat mencakup:

• branch protection,
• code review,
• signed artifact,
• protected CI/CD secrets,
• restricted deployment permission,
• integrity verification.

9. Security Logging and Monitoring Failures

Bayangkan attacker mencoba login:

10 kali
100 kali
10.000 kali

Tetapi aplikasi tidak mencatat aktivitas tersebut.

Secara teknis aplikasi mungkin tetap berjalan normal, tetapi organisasi kehilangan kemampuan mendeteksi serangan.

Minimal log keamanan sebaiknya mencatat:

Login Success
Login Failed
Password Change
Password Reset
Permission Change
Admin Activity
Sensitive Data Access
API Authentication Failure
Suspicious Request

Log kemudian dapat dikirim ke sistem monitoring:

Application
     │
     ▼
Centralized Logging
     │
     ▼
SIEM / Monitoring
     │
     ▼
Alert
     │
     ▼
Security / Operations Team

Tujuannya bukan sekadar menyimpan log, tetapi mendeteksi kejadian abnormal.

10. Mishandling of Exceptional Conditions

Error merupakan bagian normal dari sebuah aplikasi.

Yang menjadi masalah adalah bagaimana aplikasi menangani kondisi tersebut.

Contohnya response seperti:

NullPointerException
at com.company.payment.PaymentService.java:143

Database:
10.10.20.15:5432

Table:
payment_transaction

Informasi seperti ini dapat membantu attacker memahami struktur internal aplikasi.

Response kepada pengguna sebaiknya sederhana:

{
  "error": "Unable to process request"
}

Sedangkan detail teknis tetap dicatat secara internal:

Application Log
Security Log
APM
SIEM

Dengan demikian developer tetap mendapatkan informasi untuk debugging tanpa membuka detail sistem kepada pengguna.

Proteksi Dasar Aplikasi Web

Selain memahami risiko, developer perlu menerapkan security controls pada beberapa lapisan.

HTTPS

Seluruh komunikasi sebaiknya menggunakan:

HTTPS
TLS

Bukan:

HTTP

HTTPS membantu mencegah data dibaca atau dimodifikasi ketika dikirim melalui jaringan.

Security Headers

Beberapa HTTP security header dapat membantu browser melindungi pengguna.

Contohnya:

Content-Security-Policy
Strict-Transport-Security
X-Content-Type-Options
Referrer-Policy
Permissions-Policy

Contoh:

X-Content-Type-Options: nosniff

Untuk aplikasi modern, Content-Security-Policy menjadi salah satu kontrol penting untuk membatasi resource yang dapat dijalankan oleh browser.

Secure Cookie

Session cookie sebaiknya menggunakan atribut seperti:

Secure
HttpOnly
SameSite

Contoh:

Set-Cookie: SESSION=xxx;
Secure;
HttpOnly;
SameSite=Lax

HttpOnly membantu mencegah JavaScript membaca cookie tertentu, sementara Secure memastikan cookie hanya dikirim melalui koneksi HTTPS.

Input Validation

Jangan pernah berasumsi bahwa input dari client dapat dipercaya.

Browser
Mobile App
API Client
JavaScript

Semua dapat dimodifikasi oleh pengguna.

Karena itu validasi utama harus dilakukan kembali di server.

Prinsip sederhananya:

Never trust client-side input.

Proteksi API

Banyak aplikasi modern sebenarnya lebih banyak berkomunikasi melalui API dibandingkan halaman web tradisional.

Contohnya:

Web Application ───┐
                   │
Mobile App ────────┼──► API ───► Services
                   │
Partner System ────┘

Karena itu API membutuhkan proteksi tersendiri.

Beberapa kontrol penting:

Authentication
Authorization
Rate Limiting
Input Validation
Schema Validation
Token Expiration
API Gateway
Logging
Monitoring
Request Size Limit

Jangan menganggap endpoint aman hanya karena tidak ditampilkan di halaman web.

Attacker dapat memanggil API secara langsung.

Rate Limiting

Endpoint sensitif seperti:

/login
/forgot-password
/otp
/api/search
/api/payment

sebaiknya memiliki mekanisme pembatasan request.

Contohnya:

IP/User
   │
   ▼
Rate Limiter
   │
   ├── Allowed ───► Application
   │
   └── Blocked ───► HTTP 429

Rate limiting membantu mengurangi risiko brute force dan abuse terhadap API.

Web Application Firewall

WAF dapat ditempatkan di depan aplikasi.

Internet
   │
   ▼
CDN
   │
   ▼
WAF
   │
   ▼
Reverse Proxy
   │
   ▼
Application

WAF dapat membantu mendeteksi atau memblokir pola serangan tertentu.

Tetapi perlu diingat:

WAF bukan pengganti secure coding.

Jika authorization aplikasi salah, memasang WAF tidak otomatis memperbaiki kesalahan tersebut.

Security Testing dalam Development Lifecycle

Security sebaiknya menjadi bagian dari SDLC.

Pendekatan lama:

Development
     │
     ▼
Testing
     │
     ▼
Production
     │
     ▼
Security Test

Pendekatan yang lebih baik:

Requirement
     │
     ▼
Threat Modeling
     │
     ▼
Development
     │
     ├── SAST
     ├── Secret Scanning
     └── Dependency Scanning
     │
     ▼
Testing
     │
     ├── DAST
     └── API Security Testing
     │
     ▼
Deployment
     │
     ▼
Monitoring
     │
     ▼
Continuous Improvement

Konsep ini sering disebut:

Shift Left Security

Artinya keamanan diperiksa sedini mungkin dalam proses development.

SAST dan DAST

Dua pendekatan yang umum digunakan adalah SAST dan DAST.

SAST

Static Application Security Testing menganalisis source code atau artifact tanpa harus menyerang aplikasi yang sedang berjalan.

Contohnya mendeteksi:

Hardcoded Password
SQL Injection Pattern
Unsafe Function
Weak Cryptography
Potential XSS

Flow:

Source Code
    │
    ▼
SAST Scanner
    │
    ▼
Security Findings

DAST

Dynamic Application Security Testing melakukan pengujian terhadap aplikasi yang sedang berjalan.

Running Application
        │
        ▼
DAST Scanner
        │
        ▼
HTTP Requests
        │
        ▼
Security Findings

SAST melihat aplikasi dari perspektif source code.

DAST melihat aplikasi dari perspektif aplikasi yang sudah berjalan.

Keduanya saling melengkapi.

Dependency Scanning

Dependency scanner memeriksa library yang digunakan aplikasi.

Contohnya:

pom.xml
package.json
requirements.txt
Docker Image

Scanner kemudian membandingkannya dengan database vulnerability.

Hasilnya dapat berupa:

Library
Version
CVE
Severity
Fixed Version

Developer kemudian dapat menentukan apakah dependency harus segera diperbarui.

Secret Scanning

Kesalahan yang cukup berbahaya adalah menyimpan credential di source code.

Contoh:

String password = "SuperSecretPassword";

Atau:

AWS_ACCESS_KEY
DATABASE_PASSWORD
PRIVATE_KEY
API_TOKEN

Credential sebaiknya dikelola melalui mekanisme seperti:

Environment Variable
Secret Manager
Vault
CI/CD Secret

Repository juga sebaiknya memiliki secret scanning untuk mendeteksi credential yang tidak sengaja di-commit.

Container Security

Jika aplikasi menggunakan Docker, container juga menjadi bagian dari attack surface.

Contohnya:

Application
    │
    ▼
Docker Image
    │
    ├── OS Packages
    ├── Runtime
    ├── Libraries
    └── Application

Vulnerability dapat berasal dari salah satu layer tersebut.

Beberapa praktik yang dapat diterapkan:

• gunakan base image minimal,
• hindari menjalankan container sebagai root,
• scan container image,
• update base image,
• jangan menyimpan secret di image,
• gunakan image dari sumber terpercaya.

Prinsip Least Privilege

Setiap komponen sebaiknya hanya memiliki permission yang benar-benar diperlukan.

Contohnya aplikasi hanya membutuhkan:

SELECT
INSERT
UPDATE

Tetapi database user diberikan:

SUPERUSER

Ini meningkatkan dampak jika aplikasi berhasil dieksploitasi.

Konsepnya:

Give only the minimum access required to perform the job.

Prinsip ini berlaku untuk:

Database User
Linux User
Cloud IAM
API Token
Service Account
Kubernetes
CI/CD

Defense in Depth

Tidak ada satu teknologi yang dapat memberikan keamanan 100%.

Karena itu gunakan beberapa lapisan perlindungan.

                INTERNET
                    │
                    ▼
              CDN / Anti-DDoS
                    │
                    ▼
                   WAF
                    │
                    ▼
              Reverse Proxy
                    │
                    ▼
               Application
               Security
                    │
                    ▼
               API Security
                    │
                    ▼
              Private Network
                    │
                    ▼
                Database
                    │
                    ▼
            Logging / Monitoring

Jika satu layer gagal, masih ada layer berikutnya yang memberikan perlindungan.

Inilah konsep:

Defense in Depth.

Bagaimana Menggunakan OWASP sebagai Standar Development?

OWASP sebaiknya tidak hanya digunakan ketika melakukan penetration testing.

OWASP dapat dimasukkan sejak awal proses development.

Contohnya:

Requirement
     │
     ▼
OWASP ASVS
     │
     ▼
Architecture
     │
     ▼
Threat Modeling
     │
     ▼
Development
     │
     ├── Secure Coding
     ├── SAST
     ├── Dependency Scan
     └── Secret Scan
     │
     ▼
Testing
     │
     ├── OWASP WSTG
     ├── DAST
     └── API Security Testing
     │
     ▼
Production
     │
     ├── WAF
     ├── Monitoring
     └── Vulnerability Management

Dengan pendekatan tersebut, keamanan menjadi bagian dari Software Development Lifecycle, bukan sekadar checklist sebelum aplikasi go live.

Security Checklist Sederhana

Sebelum aplikasi masuk production, minimal periksa:

Authentication

• Password disimpan menggunakan password hashing yang sesuai
• MFA tersedia untuk akun sensitif
• Login memiliki rate limiting
• Session memiliki expiration
• Cookie menggunakan Secure dan HttpOnly

Authorization

• Setiap endpoint memiliki authorization
• Ownership resource diperiksa
• Admin endpoint dilindungi
• Prinsip least privilege diterapkan

Application

• Input validation diterapkan
• Parameterized query digunakan
• Error tidak membocorkan stack trace
• Security headers dikonfigurasi
• Upload file divalidasi

Infrastructure

• Database tidak terbuka langsung ke internet
• Firewall dikonfigurasi
• HTTPS digunakan
• Service yang tidak diperlukan dimatikan
• Server dan container mendapatkan security update

Development

• SAST dijalankan
• Dependency scanning dijalankan
• Secret scanning dijalankan
• Container scanning dilakukan
• Code review dilakukan

Monitoring

• Authentication failure dicatat
• Aktivitas administrator dicatat
• Security event dimonitor
• Alert tersedia untuk aktivitas mencurigakan
• Log disimpan secara terpusat

Apakah Aplikasi yang Lulus Penetration Test Sudah Aman?

Belum tentu.

Penetration testing menggambarkan kondisi aplikasi pada waktu tertentu.

Setelah itu bisa terjadi:

New Feature
New Dependency
New Developer
New Configuration
New Infrastructure
New Vulnerability

Karena itu keamanan bukan:

Pentest
   │
   ▼
SELESAI

Tetapi sebuah siklus:

Design
  │
  ▼
Develop
  │
  ▼
Test
  │
  ▼
Deploy
  │
  ▼
Monitor
  │
  ▼
Improve
  │
  └──────────► Design

Security Bukan Hanya Tanggung Jawab Security Team

Salah satu kesalahan organisasi adalah menganggap keamanan hanya pekerjaan tim security.

Padahal keamanan melibatkan:

Developer
QA
DevOps
Infrastructure
Security
Architect
Product Owner
Management

Developer harus memahami secure coding.

DevOps harus memahami infrastructure security.

QA perlu memasukkan negative dan security testing.

Architect perlu mempertimbangkan threat model.

Management perlu memastikan proses dan governance berjalan.

Security akhirnya menjadi shared responsibility.

Penutup

Web security bukan sekadar memasang firewall, menggunakan HTTPS, atau melakukan penetration testing setahun sekali.

Keamanan harus menjadi bagian dari bagaimana aplikasi dirancang, ditulis, diuji, di-deploy, dan dimonitor.

OWASP memberikan kerangka yang sangat berguna untuk memulai proses tersebut. OWASP Top 10 membantu memahami risiko, ASVS membantu menentukan requirement keamanan, dan WSTG membantu proses pengujian.

Tujuan akhirnya bukan membuat aplikasi yang diklaim 100% tidak bisa diretas—karena klaim tersebut tidak realistis.

Tujuannya adalah membangun sistem yang memiliki risiko terukur, memiliki beberapa lapisan proteksi, mampu mendeteksi aktivitas mencurigakan, dan dapat merespons vulnerability dengan cepat.

Build security into the software, not around the software.