veza/veza-backend-api/tests/security

Security Tests - veza-backend-api

Overview

This directory contains security tests to verify that the application is protected against common security vulnerabilities, including:

• SQL Injection attacks
• Cross-Site Scripting (XSS) attacks
• Command Injection attacks
• Input validation and sanitization

Running Security Tests

Prerequisites

Security tests require the security build tag to be enabled:

go test -tags=security ./tests/security/... -v

Individual Test Suites

SQL Injection Tests:

go test -tags=security ./tests/security -run TestSQLInjection -v

XSS Tests:

go test -tags=security ./tests/security -run TestXSS -v

Command Injection Tests:

go test -tags=security ./tests/security -run TestCommandInjection -v

Sanitization Utility Tests:

go test -tags=security ./tests/security -run TestSanitizeInput -v

Test Coverage

SQL Injection Protection

Tests verify that:

• GORM uses parameterized queries (prevents SQL injection)
• User input in query parameters is safely handled
• Path parameters are validated and sanitized
• Database integrity is maintained even with malicious input

Test Payloads: 30+ SQL injection payloads including:

• ' OR '1'='1
• '; DROP TABLE users; --
• ' UNION SELECT * FROM users--
• And many more variations

XSS Protection

Tests verify that:

• HTML/JavaScript payloads are sanitized or escaped
• Dangerous URL schemes (javascript:, data:, vbscript:) are removed
• Event handlers (onclick, onerror, etc.) are stripped
• Script tags and iframes are removed or escaped

Test Payloads: 50+ XSS payloads including:

• <script>alert('XSS')</script>
• <img src=x onerror=alert('XSS')>
• javascript:alert('XSS')
• And many more variations

Command Injection Protection

Tests verify that:

• Shell command injection attempts are blocked
• Dangerous characters (;, |, &, &&, ||, `, $()) are sanitized
• System commands cannot be executed through user input

Test Payloads: 30+ command injection payloads including:

• ; ls
• | cat /etc/passwd
• `rm -rf /`
• $(whoami)
• And many more variations

Input Sanitization

Tests verify that the utils.SanitizeInput() function:

• Escapes HTML special characters
• Removes dangerous URL schemes
• Removes control characters
• Limits input length to prevent DoS

Expected Results

All security tests should PASS. If any test fails:

1. SQL Injection Test Failure: Indicates that raw SQL queries may be vulnerable. Check for:

   • Raw SQL queries using string concatenation
   • Missing parameterization in database queries
   • Direct user input in SQL queries

2. XSS Test Failure: Indicates that user input is not properly sanitized. Check for:

   • Missing sanitization in handlers
   • Unescaped output in responses
   • Missing Content-Security-Policy headers

3. Command Injection Test Failure: Indicates that system commands may be executed. Check for:

   • Use of os/exec with user input
   • Shell command execution with user-controlled data
   • Missing input validation

Integration with CI/CD

Add security tests to your CI/CD pipeline:

# Example GitHub Actions
- name: Run security tests
  run: |
    go test -tags=security ./tests/security/... -v    

Best Practices

1. Always use parameterized queries: Never concatenate user input into SQL queries
2. Sanitize all user input: Use utils.SanitizeInput() or similar functions
3. Validate input: Use validators from internal/validators package
4. Escape output: When rendering user input, always escape HTML/JavaScript
5. Use security headers: Ensure SecurityHeaders middleware is applied

Related Files

• internal/utils/sanitizer.go - Input sanitization utilities
• internal/middleware/security_headers_test.go - Security headers tests
• internal/validators/ - Input validation validators

Notes

• Security tests use in-memory SQLite database for isolation
• Tests do not require external dependencies
• All test payloads are safe and do not cause actual harm
• Tests verify protection at both application and database levels