Xss Cross Site Scripting with Api Keys
How XSS Cross-Site Scripting Manifests in API Keys
XSS vulnerabilities in API key handling occur when untrusted input is rendered in web applications without proper sanitization. In API key contexts, this often manifests through error messages, documentation pages, or admin interfaces that display key values or metadata.
A common pattern involves API keys being included in error responses when validation fails. Consider this vulnerable endpoint:
app.post('/api/v1/verify-key', (req, res) => {
const { key } = req.body;
if (!key) {
res.status(400).json({
error: `Invalid API key: ${key}`
});
}
});If an attacker submits a key containing <script>alert(1)</script>, the response will execute malicious JavaScript in the browser of anyone viewing the error message.
Another manifestation occurs in API documentation generators that display example keys. When keys are stored in databases and later displayed in admin dashboards without escaping, attackers can inject scripts that execute when administrators view key details.
API key rotation interfaces are particularly vulnerable. If the UI displays old keys during rotation and doesn't sanitize the display, an attacker with key creation privileges can inject XSS payloads that persist in the admin interface.
Log aggregation systems that display API key metadata in web interfaces also present XSS opportunities. Keys containing special characters can break HTML contexts, allowing script execution when logs are viewed through web consoles.
API Keys-Specific Detection
Detecting XSS in API key contexts requires testing both the API endpoints and any web interfaces that display key-related data. middleBrick's scanning methodology includes specialized XSS detection for API key scenarios.
The scanner tests for reflected XSS by submitting API keys containing common payload patterns like <script>alert(document.domain)</script> and variations with HTML entities, JavaScript pseudo-protocols, and event handlers. It monitors responses for successful script execution or HTML injection.
For stored XSS scenarios, middleBrick analyzes endpoints that might display key metadata, error messages, or documentation. The scanner checks if special characters in API keys are properly escaped when rendered in HTML contexts.
middleBrick's LLM security module also detects if API keys are exposed in system prompts or AI model outputs, which could lead to XSS when those outputs are rendered in web interfaces.
Manual testing should include:
- Submitting keys with
<img src=x onerror=alert(1)>to test HTML injection - Using
javascript:alert(document.cookie)in key values to test JavaScript execution - Testing with Unicode characters that might break HTML parsing
- Checking if key metadata fields allow HTML content
The scanner provides severity ratings based on exploitability and impact, with findings mapped to OWASP API Top 10 categories A4 (Injection) and A7 (Security Misconfiguration).
API Keys-Specific Remediation
Remediation for XSS in API key contexts follows standard XSS prevention practices, with specific considerations for API key workflows.
The most critical fix is proper output encoding. When displaying API keys or key-related data in web interfaces, always use context-appropriate encoding:
// Node.js/Express example
app.get('/api-keys/:id', (req, res) => {
const key = getKeyById(req.params.id);
// Use a templating engine with auto-escaping
// or manually encode HTML entities
const safeKey = escapeHtml(key.value);
res.render('key-details', { key: safeKey });
});
// Utility function for HTML escaping
function escapeHtml(str) {
return str
.replace(/&/g, '&')
.replace(//g, '>')
.replace(/"/g, '"')
.replace(/'/g, ''')
.replace(///g, '/');
}For API error responses that might include key values, implement strict validation and avoid echoing user input:
app.post('/api/v1/verify-key', (req, res) => {
const { key } = req.body;
if (!key || typeof key !== 'string') {
return res.status(400).json({
error: 'Invalid API key format'
});
}
if (!isValidKeyFormat(key)) {
return res.status(400).json({
error: 'Invalid API key'
});
}
// Process valid key
});Implement Content Security Policy headers to mitigate XSS impact:
// Express middleware
app.use((req, res, next) => {
res.setHeader('Content-Security-Policy',
"default-src 'self'; script-src 'self' 'nonce-random123';");
next();
});For API documentation systems, sanitize example keys before rendering:
function sanitizeKeyForDisplay(key) {
// Mask sensitive portions
return key.replace(/(.{4}).*(.{4})/, '$1***$2');
// Or use a placeholder entirely
// return 'sk-xxxxxxxxxxxxxxx';
}Consider implementing input validation that rejects keys containing suspicious characters when they're not expected in your key format.
Related CWEs: inputValidation
| CWE ID | Name | Severity |
|---|---|---|
| CWE-20 | Improper Input Validation | HIGH |
| CWE-22 | Path Traversal | HIGH |
| CWE-74 | Injection | CRITICAL |
| CWE-77 | Command Injection | CRITICAL |
| CWE-78 | OS Command Injection | CRITICAL |
| CWE-79 | Cross-site Scripting (XSS) | HIGH |
| CWE-89 | SQL Injection | CRITICAL |
| CWE-90 | LDAP Injection | HIGH |
| CWE-91 | XML Injection | HIGH |
| CWE-94 | Code Injection | CRITICAL |