Belajar Performance Test Engineer - Security in Load Tests

#Pendahuluan

Setelah di episode 18 kita memahami network & latency testing, kini saatnya membahas aspek yang krusial tetapi sering diabaikan: keamanan dalam load testing. Load test yang tidak hati-hati bisa mempengaruhi production user, memicu rate limiting, atau bahkan memicu DDoS protection yang memblokir traffic legitimate. Load test yang tidak aman bisa juga membocorkan credentials atau data sensitif.

Security dalam load testing bukan hanya soal melindungi sistem — tetapi juga melindungi data test, credentials, dan memastikan test tidak menyebabkan kerusakan yang tidak direncanakan.

#Safe Load Testing Practices

#Prinsip Dasar

1. Isolation: test di environment terpisah dari production
2. Controlled scope: batasi target test ke resource tertentu
3. Communication: beri tahu tim sebelum menjalankan load test
4. Monitoring: pantau dampak real-time selama test
5. Kill switch: siapkan cara menghentikan test segera jika ada masalah

#Environment Isolation

# Jalankan test ke staging environment
k6 run --env BASE_URL=https://staging.example.com script.js
 
# Jangan pernah test langsung ke production tanpa koordinasi

#Communication Protocol

Sebelum load test, pastikan:

• Tim SRE/ops aware dan siap memantau
• Rate limiting dikonfigurasi untuk mengizinkan test traffic
• Waktu test dijadwalkan di lalu lintas rendah
• Rollback plan siap jika ada masalah

#DDoS-Aware Testing

#Memahami DDoS Protection

Banyak platform punya DDoS protection yang otomatis memblokir traffic yang terlihat seperti serangan. Load test bisa memicu proteksi ini jika tidak dikonfigurasi dengan benar.

#Membedakan Load Test dari DDoS

#Whitelisting Load Test Traffic

# Tandai load test traffic dengan custom header
k6 run --header "X-Load-Test: true" script.js
 
# Atau gunakan IP range yang di-whitelist
k6 run --out cloud script.js  # k6 Cloud menggunakan IP yang bisa di-whitelist

#Rate Limiting Testing

#Apa itu Rate Limiting

Rate limiting membatasi jumlah request yang diterima dari satu client dalam periode waktu tertentu. Rate limiting melindungi dari abuse dan DDoS — tetapi juga bisa mempengaruhi user yang sangat aktif.

#Testing Rate Limit Behavior

// k6: test rate limiting behavior
export const options = {
  vus: 10,
  duration: '2m',
};
 
export default function () {
  const res = http.get('https://api.example.com/search?q=test');
  check(res, {
    'status 200 or 429': (r) => r.status === 200 || r.status === 429,
    'rate limit response has Retry-After': (r) => {
      if (r.status === 429) {
        return r.headers['Retry-After'] !== undefined;
      }
      return true;
    },
  });
}

#Rate Limit Headers

// Perhatikan rate limit headers
export default function () {
  const res = http.get('https://api.example.com/api');
  const remaining = parseInt(res.headers['X-RateLimit-Remaining'] || '100');
  const limit = parseInt(res.headers['X-RateLimit-Limit'] || '1000');
 
  check(res, {
    'has rate limit headers': () => remaining >= 0 && limit > 0,
  });
}

#Credential Security

#Jangan Commit Credentials

Test scripts sering berisi credentials untuk authentication. Pastikan credentials tidak pernah di-commit ke version control.

# Gunakan environment variables
k6 run --env USERNAME=testuser --env PASSWORD=testpass script.js
 
# Atau gunakan .env file (jangan commit)
echo "USERNAME=testuser" > .env
echo "PASSWORD=testpass" >> .env
echo ".env" >> .gitignore

#k6 Environment Variables

import http from 'k6/http';
 
const BASE_URL = __ENV.BASE_URL || 'https://staging.example.com';
const API_KEY = __ENV.API_KEY;
 
export default function () {
  const res = http.get(`${BASE_URL}/api/data`, {
    headers: { 'Authorization': `Bearer ${API_KEY}` },
  });
}

#Secrets Management

Untuk CI/CD, gunakan secrets management:

# GitHub Actions secrets
- name: Run load test
  env:
    API_KEY: ${{ secrets.PERF_TEST_API_KEY }}
  run: k6 run script.js

#Data Privacy dalam Testing

#Anonymize Test Data

Jika menggunakan data dari production untuk testing, pastikan data sudah dianonimkan:

# Anonymize PII data
import faker
fake = faker.Faker()
 
def anonymize_user(user):
    return {
        'id': user['id'],
        'name': fake.name(),
        'email': fake.email(),
        'phone': fake.phone_number(),
    }

#Compliance Considerations

Beberapa regulasi (GDPR, HIPAA) membatasi penggunaan data production untuk testing. Pastikan kalian memahami compliance requirements sebelum menggunakan data production.

#Monitoring Impact ke Production

#Jika Test Bocor ke Production

Jika load test traffic mencapai production, tanda-tandanya:

• Error rate tiba-tiba naik tanpa code change
• Latency spike di beberapa endpoints
• User complaints tentang lambat

#Mitigation

• Instant kill switch: hentikan semua test workers segera
• Communication: beri tahu tim support tentang kemungkinan gangguan
• Post-incident review: analisis bagaimana test bisa bocor ke production

#Penutup

Di episode 19 ini kalian telah memahami security in load tests:

• Safe practices: isolation, communication, monitoring, kill switch.
• DDoS-aware: whitelisting, realistis user agents, koordinasi.
• Rate limiting: testing behavior, headers, dan expected responses.
• Credential security: environment variables, secrets management.
• Data privacy: anonymization, compliance considerations.

Di episode 20 selanjutnya, kita akan membahas Performance & Compliance SLO — bagaimana menghubungkan performa dengan Service Level Objectives, error budgets, dan reporting untuk stakeholder. Siapkan SLO document kalian!