Technical interview untuk posisi Application Security Engineer (AppSec) biasanya tidak hanya menguji apakah kita hafal OWASP Top 10. Interviewer ingin melihat apakah kita mampu:

memahami cara kerja aplikasi dari frontend sampai backend,
menemukan dan menjelaskan vulnerability,
menilai risiko dan severity,
membaca source code,
memahami authentication dan authorization,
mengamankan API,
melakukan threat modeling,
menggunakan security tooling,
bekerja dengan developer,
dan menerjemahkan temuan security menjadi perbaikan yang realistis.

Artikel ini dapat digunakan sebagai roadmap belajar, checklist, sekaligus bank pertanyaan interview.

1. Application Security Fundamentals

Pertanyaan dasar

1. Apa yang dimaksud dengan Application Security?

Jawaban ideal harus mencakup perlindungan aplikasi dari vulnerability dan abuse sepanjang lifecycle aplikasi, mulai dari design, development, testing, deployment, sampai maintenance.

2. Apa perbedaan Application Security, Cybersecurity, dan Network Security?

Pahami scope masing-masing.

Network Security → jaringan dan komunikasi
Cybersecurity → cakupan keamanan sistem secara luas
Application Security → keamanan aplikasi, kode, API, dependency, architecture, dan proses development

3. Apa itu vulnerability, threat, risk, exploit, dan impact?

Jangan mencampur istilah.

Contoh:

SQL Injection adalah vulnerability. Attacker yang mengeksploitasinya merupakan threat actor. SQL injection dapat dieksploitasi menggunakan payload tertentu. Dampaknya dapat berupa unauthorized database access.

4. Apa perbedaan vulnerability dan security misconfiguration?

Misalnya:

vulnerability pada logic authorization,
tetapi konfigurasi endpoint admin yang terbuka juga dapat menjadi security misconfiguration.

5. Apa prinsip CIA Triad?

Confidentiality
Integrity
Availability

Berikan contoh dampak masing-masing pada aplikasi.

6. Apa itu defense in depth?

Jangan hanya mengandalkan satu security control.

Contoh:

Authentication
      ↓
Authorization
      ↓
Input validation
      ↓
Business rule validation
      ↓
Database access control
      ↓
Monitoring

2. Secure SDLC

Pertanyaan

7. Apa itu Secure SDLC?

Jelaskan bagaimana security dimasukkan ke setiap tahap development.

Requirement
    ↓
Design
    ↓
Development
    ↓
Testing
    ↓
Deployment
    ↓
Monitoring

8. Apa perbedaan Shift Left Security dan DevSecOps?

Shift Left berarti security dipertimbangkan lebih awal.

DevSecOps lebih luas: security diintegrasikan ke workflow development dan operations.

9. Bagaimana cara memasukkan security ke CI/CD?

Contoh:

Developer
   ↓
Pull Request
   ↓
SAST
   ↓
Dependency Scan
   ↓
Secret Scan
   ↓
Unit/Security Tests
   ↓
Build
   ↓
DAST
   ↓
Deploy

10. Apakah semua vulnerability harus membuat pipeline gagal?

Ini pertanyaan yang bagus untuk menguji maturity.

Jawaban tidak seharusnya:

“Ya, semua vulnerability harus fail.”

Pertimbangkan:

severity,
exploitability,
confidence,
environment,
business context,
false positive,
compensating controls.

3. OWASP

Kuasai OWASP Top 10, tetapi jangan berhenti pada definisinya.

Untuk setiap kategori pahami:

cara kerja,
contoh vulnerability,
cara menemukan,
impact,
remediation,
contoh kode vulnerable,
contoh kode secure.

Kategori yang perlu dikuasai antara lain:

Broken Access Control
Cryptographic Failures
Injection
Insecure Design
Security Misconfiguration
Vulnerable and Outdated Components
Identification and Authentication Failures
Software and Data Integrity Failures
Security Logging and Monitoring Failures
SSRF

4. Authentication

Pertanyaan interview

11. Apa perbedaan authentication dan authorization?

Authentication:

Who are you?

Authorization:

What are you allowed to do?

12. Bagaimana cara mendesain authentication yang aman?

Bahas:

password hashing,
session/token,
MFA,
rate limiting,
account recovery,
session expiration,
secure cookies,
login protection.

13. Apa perbedaan hashing, encryption, dan encoding?

Ini pertanyaan fundamental.

Hashing

One-way transformation.

password → hash

Encryption

Reversible menggunakan key.

plaintext → ciphertext → plaintext

Encoding

Representasi data.

"hello" → Base64

Base64 bukan encryption.

14. Bagaimana password seharusnya disimpan?

Jangan:

SHA256(password)

Gunakan password hashing algorithm yang memang dirancang untuk password, seperti:

Argon2id
bcrypt
scrypt

Dengan konfigurasi yang sesuai.

15. Apa itu salt?

Random value yang digunakan bersama password sebelum hashing sehingga password yang sama tidak menghasilkan hash yang sama.

16. Apa itu password pepper?

Secret tambahan yang tidak disimpan bersama database password.

5. Session Security

17. Apa itu session fixation?

Attacker membuat korban menggunakan session ID yang sudah diketahui attacker.

18. Apa itu session hijacking?

Attacker memperoleh session credential korban dan menggunakannya untuk impersonation.

19. Apa atribut cookie yang perlu diperhatikan?

Minimal pahami:

Secure
HttpOnly
SameSite
Domain
Path

20. Apa fungsi HttpOnly?

Mencegah JavaScript mengakses cookie melalui mekanisme seperti:

document.cookie

Tetapi HttpOnly tidak mencegah semua bentuk XSS.

6. JWT

21. Apa itu JWT?

Pahami struktur:

Header.Payload.Signature

22. Apakah JWT terenkripsi?

Tidak secara default.

JWT biasanya encoded, bukan encrypted.

23. Apa vulnerability umum JWT?

Pahami:

algorithm confusion,
weak signing secret,
improper signature verification,
accepting unsigned tokens,
excessive token lifetime,
token leakage,
insufficient authorization checks.

24. Apakah JWT selalu lebih baik daripada session?

Tidak.

Pemilihan tergantung architecture dan kebutuhan.

7. Authorization dan Access Control

Ini merupakan area yang sangat penting untuk AppSec.

25. Apa itu Broken Access Control?

User dapat melakukan action atau mengakses resource yang seharusnya tidak boleh dilakukan.

26. Apa itu IDOR?

Contoh:

GET /api/users/1001/profile

User A mengganti:

1001 → 1002

dan dapat melihat data User B.

Masalah sebenarnya bukan sekadar parameter ID.

Masalahnya adalah:

server tidak memastikan bahwa requester memiliki authorization terhadap resource tersebut.

27. Bagaimana mencegah IDOR?

Authorization harus dilakukan server-side.

request
   ↓
authenticate user
   ↓
identify resource
   ↓
check authorization
   ↓
allow / deny

Jangan hanya mengandalkan:

hidden field,
frontend validation,
disabled button,
UUID,
obfuscation.

28. Apakah UUID mencegah IDOR?

Tidak.

UUID membuat enumeration lebih sulit, tetapi bukan authorization control.

29. Apa perbedaan horizontal dan vertical privilege escalation?

Horizontal:

User A → User B

Vertical:

User → Admin

30. Apakah frontend authorization cukup?

Tidak.

Frontend authorization terutama untuk UX.

Security boundary harus berada di backend.

8. API Security

Pahami REST API secara mendalam.

Pertanyaan

31. Apa security issue yang umum pada REST API?

Misalnya:

broken authorization,
excessive data exposure,
mass assignment,
rate-limit bypass,
injection,
SSRF,
improper authentication,
business logic flaws.

32. Apa itu mass assignment?

Contoh:

{
  "name": "Alice",
  "role": "admin"
}

Jika server secara otomatis menerima semua field dan langsung melakukan binding ke object internal, user mungkin dapat memodifikasi field yang seharusnya tidak boleh diubah.

33. Bagaimana mencegah mass assignment?

Gunakan explicit allowlist:

Allowed:
name
email

Not allowed:
role
isAdmin
permissions

34. Apakah API harus selalu menggunakan POST untuk data sensitif?

Tidak sesederhana itu.

POST sendiri bukan security control.

Yang penting:

HTTPS,
authentication,
authorization,
validation,
appropriate caching policy,
secure logging,
proper handling of sensitive data.

9. Input Validation

35. Apakah input validation dapat mencegah semua attack?

Tidak.

Validation harus disesuaikan dengan konteks.

36. Apa perbedaan allowlist dan blocklist?

Allowlist:

hanya menerima format yang diperbolehkan

Blocklist:

menolak beberapa pola yang diketahui berbahaya

Allowlist biasanya lebih robust ketika memungkinkan.

37. Di mana validation harus dilakukan?

Frontend validation berguna untuk UX.

Backend validation wajib karena client tidak trusted.

10. SQL Injection

Pahami:

SELECT * FROM users
WHERE username = '$username'

Jika input dimasukkan langsung ke query, attacker dapat memanipulasi query.

38. Bagaimana mencegah SQL Injection?

Gunakan parameterized query / prepared statement.

Bukan:

string concatenation

39. Apakah ORM otomatis mencegah SQL Injection?

Tidak selalu.

Raw query dan dynamic SQL tetap dapat rentan.

11. XSS

Pahami tiga jenis utama:

Reflected XSS
Stored XSS
DOM-based XSS

40. Apa perbedaan XSS dan CSRF?

XSS:

attacker menjalankan script dalam security context aplikasi.

CSRF:

attacker memaksa browser korban melakukan request yang korban berwenang lakukan.

41. Apakah HttpOnly mencegah XSS?

Tidak.

HttpOnly membantu melindungi cookie dari pembacaan JavaScript, tetapi tidak menghilangkan vulnerability XSS.

42. Bagaimana mencegah XSS?

Tergantung context:

output encoding,
contextual escaping,
safe DOM APIs,
sanitization,
Content Security Policy,
avoiding dangerous HTML injection.

12. CSRF

43. Bagaimana CSRF terjadi?

Contoh:

Victim login ke bank
       ↓
Victim membuka malicious website
       ↓
Browser mengirim request ke bank
       ↓
Session cookie ikut terkirim

44. Cara mencegah CSRF?

Pahami:

CSRF token,
SameSite cookie,
Origin checking,
Referer validation sebagai defense tertentu.

13. SSRF

45. Apa itu SSRF?

Server melakukan request ke destination yang dikontrol attacker.

Contoh:

POST /fetch

url=https://attacker.example

46. Mengapa SSRF berbahaya?

Server mungkin memiliki akses ke resource yang tidak dapat diakses attacker secara langsung.

Misalnya:

Internet
   ↓
Application Server
   ↓
Internal Service

47. Bagaimana mitigasi SSRF?

Bahas:

destination allowlist,
URL parsing yang benar,
IP validation,
DNS rebinding protection,
network egress controls,
metadata endpoint protection,
redirect handling.

Jangan hanya mengatakan:

“Block localhost.”

Karena SSRF dapat menggunakan representasi IP dan teknik lain.

14. Business Logic Vulnerability

Ini area yang sering membedakan AppSec engineer berpengalaman dengan scanner operator.

Pertanyaan

48. Apa itu business logic vulnerability?

Vulnerability yang muncul karena aplikasi mengimplementasikan business rule secara tidak aman.

Contoh:

Harga = 100
Quantity = -1

Total = -100

Jika sistem menerima quantity negatif, logic pembayaran dapat disalahgunakan.

49. Mengapa business logic bug sulit ditemukan SAST/DAST?

Karena scanner tidak selalu memahami:

business rules,
intended workflow,
user roles,
state transitions,
economic assumptions.

50. Bagaimana cara menemukan business logic flaw?

Pahami workflow.

Contoh:

Create order
    ↓
Apply coupon
    ↓
Calculate price
    ↓
Pay
    ↓
Confirm order

Kemudian tanyakan:

apakah step dapat dilewati?
dapat diulang?
dapat dilakukan out of order?
dapat dilakukan dengan user berbeda?
apakah state dapat dimanipulasi?

15. Race Condition

51. Apa itu race condition?

Dua atau lebih request memproses state yang sama secara bersamaan sehingga menghasilkan keadaan yang tidak semestinya.

Contoh:

Balance = $100

Request A → withdraw $100
Request B → withdraw $100

Keduanya membaca balance = $100

52. Bagaimana mencegah race condition?

Tergantung sistem:

transaction,
locking,
atomic operation,
optimistic concurrency,
unique constraint,
idempotency.

16. Cryptography

Pahami konsep:

symmetric encryption,
asymmetric encryption,
hashing,
MAC,
digital signature,
key management,
random number generation.

Pertanyaan

53. AES vs RSA?

AES:

symmetric
cepat
membutuhkan shared secret

RSA:

asymmetric
public/private key
relatif lebih mahal

54. Apa itu encryption at rest dan encryption in transit?

At rest:

database / disk / backup

In transit:

client ↔ server

Biasanya menggunakan TLS untuk komunikasi jaringan.

55. Apa kesalahan cryptography yang umum?

hardcoded keys,
weak random,
obsolete algorithms,
improper key management,
reuse nonce/IV pada kondisi yang tidak boleh,
custom cryptography.

17. Secrets Management

56. Apakah API key di frontend selalu secret?

Tidak.

Jika aplikasi memang harus mengirim credential ke browser, credential tersebut pada praktiknya dapat dilihat user.

Pertanyaan yang lebih penting:

Apa privilege credential tersebut?

57. Bagaimana mengelola secret?

Hindari:

Git repository
source code
Docker image
frontend bundle
logs

Gunakan secret-management mechanism yang sesuai.

58. Bagaimana menangani secret yang terlanjur masuk Git?

Jangan hanya menghapus file.

Lakukan:

revoke/rotate credential,
remove dari source,
audit usage,
clean history jika diperlukan,
tambahkan secret scanning.

18. Dependency Security

59. Bagaimana menangani vulnerable dependency?

Jangan otomatis:

“Update semuanya.”

Evaluasi:

affected version,
exploitability,
reachable code,
application exposure,
available patch,
breaking changes,
compensating controls.

60. Apa itu SCA?

Software Composition Analysis.

Digunakan untuk mendeteksi:

vulnerable dependencies,
license issues,
dependency inventory,
transitive dependencies.

19. SAST, DAST, IAST

Pahami perbedaannya.

Tool	Fokus
SAST	Source/code
DAST	Running application
IAST	Application runtime + instrumentation
SCA	Dependencies
Secret Scanner	Credentials/secrets

61. Apakah SAST dapat menemukan semua vulnerability?

Tidak.

Terutama sulit untuk:

business logic,
authorization context,
runtime configuration,
complex distributed behavior.

62. Apakah DAST dapat menemukan semua vulnerability?

Tidak.

DAST memiliki keterbatasan pada:

authenticated flows,
business logic,
unreachable endpoints,
complex workflows,
source-level issues.

20. Threat Modeling

63. Apa itu threat modeling?

Proses sistematis untuk mengidentifikasi:

assets,
trust boundaries,
threats,
attack surfaces,
mitigations.

64. Apa itu STRIDE?

Spoofing
Tampering
Repudiation
Information Disclosure
Denial of Service
Elevation of Privilege

65. Bagaimana melakukan threat modeling API?

Mulai dari:

User
 ↓
Frontend
 ↓
API Gateway
 ↓
Application
 ↓
Database
 ↓
Third-party service

Identifikasi:

trust boundary,
authentication,
authorization,
sensitive data,
privileged operations,
external dependencies.

21. Secure Code Review

66. Apa yang Anda cari ketika melakukan code review security?

Checklist:

Authentication
Authorization
Input validation
Output encoding
Secrets
Cryptography
Error handling
Logging
File handling
Database access
SSRF
Deserialization
Concurrency
Business logic

67. Bagaimana Anda memprioritaskan code review?

Fokus dahulu pada:

authentication,
authorization,
sensitive data,
privileged operations,
external input,
cryptographic operations,
payment/business logic.

22. File Upload

68. Apa risiko file upload?

malicious file,
executable upload,
path traversal,
MIME confusion,
parser vulnerability,
stored XSS,
oversized file / DoS.

69. Apakah cukup memeriksa extension?

Tidak.

Pertimbangkan:

allowlist extension,
MIME/content validation,
file signature,
filename normalization,
storage isolation,
size limits,
malware scanning sesuai kebutuhan.

23. Path Traversal

Contoh:

GET /download?file=../../etc/passwd

Pahami:

canonicalization,
path normalization,
allowlist,
sandbox/storage boundary.

Jangan hanya melakukan string replacement:

../ → ""

24. Deserialization

70. Apa itu insecure deserialization?

Aplikasi menerima serialized object dari sumber yang tidak dipercaya dan memprosesnya secara unsafe.

Dampak dapat mencakup:

privilege manipulation,
data tampering,
denial of service,
bahkan remote code execution pada teknologi tertentu.

25. Security Headers

Kenali:

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

Pahami fungsi dan trade-off masing-masing.

26. TLS

71. Apakah HTTPS berarti aplikasi aman?

Tidak.

HTTPS terutama melindungi komunikasi dari interception/tampering pada jalur komunikasi.

Aplikasi tetap dapat memiliki:

IDOR,
SQL Injection,
XSS,
business logic flaw,
authentication flaw.

27. Logging dan Monitoring

72. Apa yang harus dicatat?

Contohnya:

authentication events,
authorization failures,
suspicious requests,
privilege changes,
sensitive operations,
security events.

73. Apa yang tidak boleh dimasukkan ke log?

Hindari credential dan data sensitif yang tidak diperlukan.

Contoh:

password
session token
API secret
private key

28. Vulnerability Assessment

74. Bagaimana Anda memvalidasi vulnerability?

Workflow:

Finding
 ↓
Reproduce
 ↓
Understand root cause
 ↓
Determine affected scope
 ↓
Determine impact
 ↓
Determine exploitability
 ↓
Assign severity
 ↓
Recommend remediation

75. Apa yang membuat vulnerability menjadi high severity?

Jangan hanya melihat nama vulnerability.

Pertimbangkan:

impact,
exploitability,
privileges required,
attack complexity,
user interaction,
exposure,
business context.

29. CVSS

Pahami konsep CVSS:

Attack Vector
Attack Complexity
Attack Requirements
Privileges Required
User Interaction
Confidentiality
Integrity
Availability

Jangan menganggap:

CVSS score = business risk

CVSS adalah salah satu input dalam risk assessment.

30. False Positive

76. Apa itu false positive?

Tool melaporkan vulnerability yang sebenarnya tidak exploitable atau tidak berlaku dalam konteks aplikasi.

77. Bagaimana menangani false positive?

Validasi manual.

Jangan:

“Scanner bilang critical, jadi critical.”

31. Incident Response

78. Apa yang Anda lakukan jika menemukan vulnerability critical di production?

Contoh pendekatan:

Validate
 ↓
Assess exposure
 ↓
Contain
 ↓
Notify stakeholders
 ↓
Remediate
 ↓
Verify fix
 ↓
Monitor
 ↓
Document

32. Secure Architecture

Interview dapat memberikan skenario:

“Kami memiliki frontend, API, database, Redis, dan third-party payment provider. Bagaimana Anda mengamankannya?”

Bahas:

trust boundaries,
authentication,
authorization,
network segmentation,
secret management,
encryption,
least privilege,
validation,
monitoring,
failure modes.

33. Cloud Security untuk AppSec

Pahami konsep:

IAM
least privilege
security groups
object storage permissions
metadata services
secrets management
KMS
logging
container security
serverless security.

Pertanyaan contoh:

Bagaimana SSRF pada cloud environment dapat menjadi lebih serius?

Jawab dengan menjelaskan bahwa server yang berhasil dipaksa melakukan request internal mungkin memiliki akses ke internal services atau metadata service, tergantung konfigurasi platform.

34. Container Security

Pahami:

Dockerfile
 ↓
Image
 ↓
Registry
 ↓
Runtime

Security concern:

vulnerable base image,
running as root,
embedded secrets,
excessive privileges,
unnecessary packages,
exposed ports,
image provenance.

35. Kubernetes Security

Minimal pahami:

RBAC,
ServiceAccount,
Secrets,
NetworkPolicy,
Pod Security,
admission control,
container privileges,
API server exposure.

36. Security Testing

Interviewer bisa bertanya:

“Bagaimana Anda menguji endpoint berikut?”

POST /api/orders

Jawaban jangan hanya:

“Saya scan dengan Burp Suite.”

Buat methodology:

Understand endpoint
 ↓
Authentication testing
 ↓
Authorization testing
 ↓
Input validation
 ↓
Business logic
 ↓
Parameter manipulation
 ↓
Race condition
 ↓
Rate limiting
 ↓
Error handling
 ↓
Data exposure

37. Burp Suite

Jika diminta menjelaskan workflow:

Proxy
 ↓
Target mapping
 ↓
Request inspection
 ↓
Repeater
 ↓
Intruder
 ↓
Authorization testing
 ↓
Automation/scanning
 ↓
Manual validation

Pahami juga mengapa Repeater sering sangat penting untuk AppSec testing manual.

38. Scenario-Based Interview

Pertanyaan scenario biasanya lebih penting daripada hafalan definisi.

Skenario 1

User biasa dapat mengakses /admin/users.

Apa yang Anda lakukan?

Jawaban harus membahas:

reproduce,
authentication state,
authorization check,
HTTP method,
object/action,
impact,
remediation.

Skenario 2

API mengembalikan 200 tetapi frontend menyembunyikan data.

Apakah aman?

Tidak otomatis.

Frontend bukan security boundary.

Skenario 3

Endpoint menggunakan UUID sehingga IDOR dianggap mustahil.

Bagaimana respons Anda?

UUID bukan authorization mechanism.

Test apakah user A dapat mengakses UUID milik user B.

Skenario 4

Scanner menemukan SQL Injection tetapi developer mengatakan ORM sudah digunakan.

Apa yang dilakukan?

Inspect implementation.

Cari:

raw SQL,
string concatenation,
dynamic query,
unsafe query construction.

Skenario 5

Developer mengatakan vulnerability hanya bisa dieksploitasi oleh authenticated user.

Apakah otomatis low severity?

Tidak.

Authenticated attacker tetap dapat memiliki impact besar.

39. Secure Design Questions

Contoh pertanyaan:

“Design authentication untuk aplikasi banking.”

Bahas:

Login
 ↓
MFA
 ↓
Session/token
 ↓
Authorization
 ↓
Sensitive transaction verification
 ↓
Audit logging
 ↓
Monitoring

Jangan hanya fokus pada login.

Security harus mencakup seluruh transaction lifecycle.

40. Coding Questions

AppSec Engineer kadang diminta membaca atau memperbaiki kode.

Contoh:

String query =
    "SELECT * FROM users WHERE id = " + userId;

Pertanyaan:

Apa masalahnya?

Jawaban:

SQL Injection jika userId berasal dari input tidak terpercaya.

Contoh:

if (user.isAdmin()) {
    showAdminPanel();
}

Pertanyaan:

Apakah ini cukup untuk authorization?

Belum tentu.

Harus dipastikan server-side authorization dilakukan pada setiap privileged operation, bukan sekadar menyembunyikan UI.

41. Pertanyaan tentang Security Mindset

Interviewer sering memberikan pertanyaan seperti:

“Apa hal pertama yang Anda lakukan ketika diberikan aplikasi baru?”

Jawaban yang matang:

Understand architecture
        ↓
Identify assets
        ↓
Identify trust boundaries
        ↓
Map attack surface
        ↓
Understand authentication
        ↓
Understand authorization
        ↓
Identify sensitive workflows
        ↓
Test high-risk areas

42. Pertanyaan yang Menguji Pengalaman Nyata

Siapkan jawaban untuk:

“Ceritakan vulnerability paling menarik yang pernah Anda temukan.”

Gunakan format:

Context
 ↓
Observation
 ↓
Hypothesis
 ↓
Testing
 ↓
Root cause
 ↓
Impact
 ↓
Remediation

Jangan hanya menceritakan payload.

Yang ingin diketahui interviewer adalah cara berpikir Anda.

“Bagaimana Anda menemukan vulnerability tersebut?”

Jelaskan reasoning.

Contoh:

Observed endpoint
        ↓
Noticed object identifier
        ↓
Changed identifier
        ↓
Compared authorization behavior
        ↓
Confirmed cross-user access

“Bagaimana Anda menjelaskan vulnerability kepada developer?”

Fokus pada:

root cause,
reproducibility,
impact,
remediation.

Bukan menyalahkan developer.

43. Pertanyaan Behavioral yang Tetap Technical

“Developer tidak setuju dengan finding Anda. Apa yang Anda lakukan?”

Jawaban ideal:

reproduce bersama,
tunjukkan evidence,
jelaskan threat model,
diskusikan impact,
dengarkan konteks developer,
cari remediation yang feasible,
dokumentasikan keputusan.

“Mana yang lebih penting: security atau usability?”

Jawaban matang:

Keduanya harus dipertimbangkan berdasarkan risk dan business context. Security control yang terlalu berat dapat mendorong pengguna atau developer mencari workaround, sementara kontrol yang terlalu lemah dapat menciptakan exposure.

44. Pertanyaan yang Sering Menjebak

“Apakah POST aman dari CSRF?”

Tidak.

Method HTTP bukan CSRF protection.

“Apakah HTTPS mencegah SQL Injection?”

Tidak.

“Apakah JWT aman?”

JWT adalah format/token mechanism, bukan jaminan keamanan.

“Apakah UUID mencegah IDOR?”

Tidak.

“Apakah WAF mencegah SQL Injection?”

WAF dapat menjadi defense layer, tetapi bukan pengganti secure coding.

“Apakah encryption membuat data aman?”

Tidak otomatis.

Key management, access control, implementation, dan threat model tetap penting.

“Apakah frontend validation merupakan security control?”

Frontend validation membantu UX, tetapi server harus melakukan validasi dan authorization sendiri.

45. Pertanyaan Advanced

Untuk level Senior AppSec, siapkan:

Architecture

Bagaimana threat modeling microservices?
Bagaimana mengamankan service-to-service communication?
Bagaimana menangani authorization lintas service?
Apa risiko API Gateway?
Bagaimana mengamankan event-driven architecture?

Identity

OAuth 2.0 vs OpenID Connect?
Access token vs refresh token?
PKCE?
Token rotation?
Session revocation?

Cloud

IAM privilege escalation?
SSRF terhadap cloud metadata?
Object storage exposure?
Secrets management?
Workload identity?

Supply Chain

Dependency confusion?
Typosquatting?
Malicious package?
Lockfile?
SBOM?
Artifact signing?

Application Logic

Race condition?
Replay attack?
Idempotency?
State machine abuse?
Multi-step authorization bypass?

46. OAuth 2.0 dan OIDC

Minimal pahami:

User
 ↓
Authorization Server
 ↓
Authorization Code
 ↓
Client
 ↓
Access Token
 ↓
Resource Server

Bedakan:

OAuth 2.0

Authorization.

OpenID Connect

Authentication/identity layer di atas OAuth 2.0.

Pahami juga:

authorization code,
PKCE,
redirect URI,
state,
nonce,
access token,
refresh token.

47. Security Testing dalam CI/CD

Salah satu pertanyaan yang sangat mungkin muncul:

“Bagaimana Anda mencegah vulnerability masuk production?”

Jawaban:

Developer
   ↓
Pre-commit checks
   ↓
Pull Request
   ↓
SAST
   ↓
SCA
   ↓
Secret scanning
   ↓
Security unit tests
   ↓
Build
   ↓
DAST/API testing
   ↓
Deployment
   ↓
Runtime monitoring

Tetapi jangan mengklaim bahwa automation menggantikan security engineer.

Automation menangani pola yang dapat diotomatisasi.

Security engineer menangani:

architecture,
threat modeling,
business logic,
complex authorization,
manual investigation,
risk decisions.

48. Vulnerability Remediation

Interviewer dapat bertanya:

“Anda menemukan vulnerability. Apa yang Anda berikan kepada developer?”

Report ideal:

Title
Severity
Affected component
Description
Precondition
Steps to reproduce
Evidence
Impact
Root cause
Remediation
References

Untuk vulnerability kompleks, tambahkan:

Attack scenario
Affected users
Exploitability
Business impact
Suggested test case

49. Bagaimana Menjawab Technical Interview dengan Baik

Jangan menjawab seperti ensiklopedia.

Gunakan pola:

Definition

Apa masalahnya?

Mechanism

Bagaimana terjadi?

Example

Berikan contoh sederhana.

Impact

Apa yang dapat dilakukan attacker?

Mitigation

Bagaimana memperbaikinya?

Contoh:

“IDOR adalah authorization flaw ketika user dapat mengakses object milik user lain. Biasanya terjadi ketika server menerima object ID tetapi tidak memeriksa ownership atau permission. Misalnya user A mengganti /orders/1001 menjadi /orders/1002 dan mendapatkan order user B. Mitigasinya adalah melakukan server-side authorization check terhadap resource tersebut pada setiap request.”

Ini jauh lebih kuat daripada sekadar:

“IDOR adalah Insecure Direct Object Reference.”

50. Checklist Belajar Sebelum Interview

Fundamental

Web Security

Identity

API

Application

Cryptography

DevSecOps

Cloud

Security Process

51. 20 Pertanyaan yang Paling Layak Dilatih

Jika waktu belajar terbatas, prioritaskan pertanyaan berikut:

Apa perbedaan authentication dan authorization?
Bagaimana Anda menemukan dan membuktikan IDOR?
Bagaimana mencegah broken access control?
Mengapa frontend authorization tidak cukup?
Bagaimana mencegah SQL Injection?
Apa perbedaan XSS dan CSRF?
Bagaimana mencegah SSRF?
Bagaimana password harus disimpan?
Apa risiko JWT?
Apa perbedaan OAuth 2.0 dan OIDC?
Bagaimana Anda melakukan security code review?
Bagaimana melakukan threat modeling?
Apa perbedaan SAST, DAST, SCA, dan IAST?
Bagaimana security dimasukkan ke CI/CD?
Bagaimana menilai severity sebuah vulnerability?
Bagaimana menemukan business logic vulnerability?
Bagaimana menangani race condition?
Bagaimana menangani secret yang bocor ke Git?
Bagaimana mengamankan API?
Ceritakan vulnerability yang pernah Anda temukan dan bagaimana Anda memvalidasinya.

52. Level Senior: Jangan Hanya Menjawab “Apa”, Jelaskan “Mengapa”

Perbedaan kandidat junior dan senior sering terlihat dari kedalaman reasoning.

Junior mungkin menjawab:

“Gunakan parameterized query untuk mencegah SQL Injection.”

Senior akan mampu menjelaskan:

“Masalahnya terjadi karena data yang dikontrol user menjadi bagian dari SQL syntax. Parameterized query memisahkan data dari query structure sehingga input tidak diperlakukan sebagai SQL syntax. Tetapi saya juga akan melihat apakah aplikasi menggunakan raw query atau dynamic SQL di bagian lain karena penggunaan ORM tidak otomatis menjamin seluruh application bebas SQL Injection.”

Pola berpikir seperti ini yang perlu dilatih.

53. Framework Berpikir untuk Hampir Semua Skenario Interview

Ketika interviewer memberikan aplikasi atau endpoint yang belum pernah Anda lihat, gunakan urutan:

1. What is the asset?
        ↓
2. Who is the attacker?
        ↓
3. What does the attacker control?
        ↓
4. What trust boundary is crossed?
        ↓
5. What security assumption exists?
        ↓
6. Can I manipulate that assumption?
        ↓
7. What happens if it succeeds?
        ↓
8. How should the application enforce the rule?

Ini dapat digunakan untuk menganalisis:

IDOR,
privilege escalation,
SSRF,
business logic,
authentication bypass,
payment abuse,
race condition,
API vulnerabilities.

Penutup

Technical interview Application Security Engineer pada akhirnya bukan kompetisi menghafal sebanyak mungkin vulnerability.

Yang perlu terlihat adalah kemampuan untuk berpikir:

Understand the system
        ↓
Identify security boundary
        ↓
Understand attacker control
        ↓
Find broken assumption
        ↓
Prove the vulnerability
        ↓
Understand impact
        ↓
Explain root cause
        ↓
Design practical remediation
        ↓
Verify the fix

Jika mampu melakukan alur tersebut, Anda tidak hanya mampu menjawab pertanyaan seperti “Apa itu IDOR?”, tetapi juga pertanyaan yang lebih penting:

“Saya memberikan aplikasi ini kepada Anda. Apa yang pertama kali Anda cari, mengapa Anda mencarinya, bagaimana Anda membuktikannya, dan bagaimana Anda memperbaikinya?”

Itulah pola berpikir yang paling penting untuk technical interview AppSec Engineer.

Kisi-Kisi Lengkap Technical Interview Application Security Engineer

1. Application Security Fundamentals

Pertanyaan dasar

2. Secure SDLC

Pertanyaan

3. OWASP

4. Authentication

Pertanyaan interview

Hashing

Encryption

Encoding

5. Session Security

6. JWT

7. Authorization dan Access Control

8. API Security

Pertanyaan

9. Input Validation

10. SQL Injection

11. XSS

12. CSRF

13. SSRF

14. Business Logic Vulnerability

Pertanyaan

15. Race Condition

16. Cryptography

Pertanyaan

17. Secrets Management

18. Dependency Security

19. SAST, DAST, IAST

20. Threat Modeling

21. Secure Code Review

22. File Upload

23. Path Traversal

24. Deserialization

25. Security Headers

26. TLS

27. Logging dan Monitoring

28. Vulnerability Assessment

29. CVSS

30. False Positive

31. Incident Response

32. Secure Architecture

33. Cloud Security untuk AppSec

34. Container Security

35. Kubernetes Security

36. Security Testing

37. Burp Suite

38. Scenario-Based Interview

Skenario 1

Skenario 2

Skenario 3

Skenario 4

Skenario 5

39. Secure Design Questions

40. Coding Questions

41. Pertanyaan tentang Security Mindset

42. Pertanyaan yang Menguji Pengalaman Nyata

“Ceritakan vulnerability paling menarik yang pernah Anda temukan.”

“Bagaimana Anda menemukan vulnerability tersebut?”

“Bagaimana Anda menjelaskan vulnerability kepada developer?”

43. Pertanyaan Behavioral yang Tetap Technical

“Developer tidak setuju dengan finding Anda. Apa yang Anda lakukan?”

“Mana yang lebih penting: security atau usability?”

44. Pertanyaan yang Sering Menjebak

“Apakah POST aman dari CSRF?”

“Apakah HTTPS mencegah SQL Injection?”

“Apakah JWT aman?”

“Apakah UUID mencegah IDOR?”

“Apakah WAF mencegah SQL Injection?”

“Apakah encryption membuat data aman?”

“Apakah frontend validation merupakan security control?”

45. Pertanyaan Advanced

Architecture

Identity

Cloud

Supply Chain

Application Logic

46. OAuth 2.0 dan OIDC

47. Security Testing dalam CI/CD

48. Vulnerability Remediation