- Created comprehensive security test suite for SQL injection, XSS, and command injection - Added 30+ SQL injection test payloads - Added 50+ XSS test payloads - Added 30+ command injection test payloads - Tests verify GORM parameterized queries protection - Tests verify input sanitization utilities - Added README documentation for security tests Phase: PHASE-5 Priority: P2 Progress: 137/267 (51.31%)
4.1 KiB
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:
-
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
-
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
-
Command Injection Test Failure: Indicates that system commands may be executed. Check for:
- Use of
os/execwith user input - Shell command execution with user-controlled data
- Missing input validation
- Use of
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
- Always use parameterized queries: Never concatenate user input into SQL queries
- Sanitize all user input: Use
utils.SanitizeInput()or similar functions - Validate input: Use validators from
internal/validatorspackage - Escape output: When rendering user input, always escape HTML/JavaScript
- Use security headers: Ensure
SecurityHeadersmiddleware is applied
Related Files
internal/utils/sanitizer.go- Input sanitization utilitiesinternal/middleware/security_headers_test.go- Security headers testsinternal/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