This document outlines security considerations and best practices for the Dragon & Garuda Network API framework.

Current Stage (Prototype)

• Mock APIs do not require authentication
• Designed for demonstration and partner evaluation only

Pilot & Production Stages

• OAuth 2.0 integration with regional identity providers:
  • China: WeChat OAuth, Alipay login, Trip.com account integration
  • Indonesia: Google OAuth, Facebook Login, OVO/DANA/GoPay account login
• API Keys for partner integrations
  • Unique keys per partner/application
  • Rate limiting and quota management per key
  • Regular key rotation policy (90 days recommended)
• JWT tokens for session management
  • Short-lived access tokens (15-30 minutes)
  • Longer-lived refresh tokens (7-30 days)
  • Secure token storage and transmission

Required for Production

• HTTPS only – All API endpoints must use TLS 1.2 or higher
• Input validation – Strict validation of all request parameters
  • Sanitize all user inputs to prevent injection attacks
  • Validate data types, ranges, and formats
  • Reject malformed requests with appropriate error codes
• Rate limiting – Protect against abuse and DDoS
  • Per-IP rate limits: 100 requests/minute (adjustable)
  • Per-API-key limits: 1000 requests/minute (adjustable)
  • Burst protection with token bucket algorithm
• CORS policies – Restrict cross-origin requests to approved domains

• Never store credit card numbers, CVV, or full PAN
• Use tokenization for all payment processing
  • China: Alipay/WeChat Pay tokenized payments
  • Indonesia: Midtrans/OVO/DANA/GoPay secure payment gateways
• Delegate payment handling to certified payment processors
• Log payment transactions for audit purposes (without sensitive data)

1. Client-side: Collect payment info via provider SDK (never direct form submission)
2. Server-side: Verify payment callbacks with provider webhooks
3. Database: Store only transaction IDs and status, never payment credentials
4. Refunds: Implement secure refund verification with dual authorization

• Minimize collection – Only collect necessary user data
• Encrypt at rest – AES-256 encryption for stored PII
  • Customer names, email addresses, phone numbers
  • Booking history and preferences
• Encrypt in transit – TLS 1.2+ for all data transmission
• Data retention – Define and enforce retention policies
  • Active bookings: retained until completion + 1 year
  • Cancelled bookings: 90 days retention
  • Analytics data: anonymized and aggregated after 30 days

• China: Comply with Cybersecurity Law and Personal Information Protection Law (PIPL)
  • Data localization requirements for Chinese citizen data
  • Host China user data in China-based data centers
• Indonesia: Comply with Personal Data Protection Law (UU PDP)
  • User consent for data collection and processing
  • Right to data access and deletion
• GDPR considerations for EU visitors
  • Even if not primary market, provide basic GDPR compliance

• DDoS protection – Leverage CDN provider DDoS mitigation
  • Aliyun/Tencent (China): Built-in Anti-DDoS
  • Telkom/CDNetworks (Indonesia): DDoS protection services
• WAF (Web Application Firewall) – Deploy at CDN edge
  • SQL injection protection
  • XSS attack prevention
  • Bot detection and blocking
• Geographic restrictions – Block traffic from unexpected regions if needed
• Cache poisoning prevention – Validate cache keys and responses

• Firewall rules – Restrict access to only CDN IP ranges
• SSH hardening – Disable password auth, use key-based only
• Regular updates – Keep OS and dependencies patched
• Intrusion detection – Deploy IDS/IPS systems (e.g., Fail2ban, OSSEC)
• Access logging – Comprehensive logs for security monitoring

• Versioned endpoints – /v1/itinerary, /v2/itinerary
• Deprecation policy
  • Minimum 6 months notice before deprecating any API version
  • Security patches applied to all supported versions
  • Critical vulnerabilities patched even in deprecated versions
• Backward compatibility – Maintain for at least 2 major versions

1. Detection – Automated monitoring and alerting
2. Assessment – Classify severity (Critical/High/Medium/Low)
3. Containment – Immediate action to limit impact
4. Notification – Inform affected partners and users within 72 hours
5. Recovery – Restore services and patch vulnerabilities
6. Post-mortem – Document incident and lessons learned

• Security issues: security@dragongaruda.network (to be established)
• Partner notifications: partners@dragongaruda.network (to be established)
• Emergency hotline: Available 24/7 during production

• API key management – Secure storage of partner credentials
  • Use environment variables or secret management services
  • Never commit credentials to version control
  • Rotate keys regularly
• Webhook verification – Validate all incoming webhooks
  • HMAC signature verification
  • Timestamp validation to prevent replay attacks
• Timeout handling – Implement circuit breakers for partner APIs
  • Prevent cascade failures
  • Graceful degradation when partners are unavailable

• Access logs – All API requests with timestamps and outcomes
• Authentication logs – All login attempts (successful and failed)
• Payment logs – All payment transactions (without sensitive data)
• Error logs – All system errors and exceptions
• Audit logs – All administrative actions and configuration changes

• Real-time monitoring – Track suspicious patterns
  • Unusual traffic spikes
  • Failed authentication attempts
  • Payment fraud indicators
• Alerts – Immediate notification for security events
  • Multiple failed login attempts
  • Unexpected geographic access patterns
  • API rate limit violations
• Regular reviews – Weekly security log analysis

• Static analysis – Regular code scanning for vulnerabilities
• Dependency scanning – Check for vulnerable dependencies
  • Automated tools: Dependabot, Snyk, or npm audit
  • Regular updates of all dependencies
• Secret scanning – Prevent credential commits
  • Pre-commit hooks for secret detection
  • Git history scanning for exposed secrets
• Code review – Security-focused peer review for all changes

• Development – Mock data, no real credentials
• Staging – Production-like but isolated
• Production – Strict access controls, all security measures active

Before Production Deployment:

• HTTPS/TLS configured with valid certificates
• OAuth/API key authentication implemented
• Rate limiting configured and tested
• WAF deployed and rules configured
• PII encryption at rest and in transit
• Payment integration security reviewed
• Logging and monitoring active
• Incident response plan documented
• Security testing completed (penetration test)
• Compliance requirements met (PIPL, UU PDP)
• Backup and disaster recovery tested
• Security training completed for operations team

1. Prototype stage – Document security architecture and requirements
2. Pilot stage – Implement basic authentication and HTTPS
3. Scale-up stage – Full security implementation with monitoring
4. Production – Continuous security assessment and improvement

For security concerns or to report vulnerabilities, contact: [security contact to be established]