Scope
This guide outlines the technical controls and operational practices needed to prevent credential exposure in client-side JavaScript and secure API endpoints from unauthorized access. It focuses on credential management, API authentication architecture, and detection capabilities for security teams managing web applications that interact with third-party APIs or internal services.
Key Concepts and Definitions
Client-Side Credential Exposure: Embedding API keys, tokens, or authentication credentials directly in JavaScript code delivered to browsers, where any user can inspect the source and extract them.
API Authentication Credential: A secret value (API key, bearer token, or service account credential) that authorizes requests to an API endpoint. These credentials often grant broad access to data repositories or service functions.
Server-Side Proxy Pattern: An architectural approach where client applications call your own backend endpoints, which then authenticate to third-party APIs using credentials stored securely on the server. The browser never sees the actual API credential.
Credential Rotation: Replacing API keys and tokens on a scheduled basis or immediately after suspected exposure, invalidating the old credential.
Requirements Breakdown
Credential Storage Requirements
Never embed credentials in client-side code. When you deliver JavaScript to a browser, you're publishing that code to anyone who requests your page. Browser developer tools make inspection trivial.
Use environment variables or secret management systems. Store API credentials in environment variables on your application server, or use a dedicated secret management service like HashiCorp Vault, AWS Secrets Manager, or Azure Key Vault. These systems provide access controls, audit logs, and rotation capabilities.
Implement the principle of least privilege for API credentials. Request the minimum scope necessary from your API provider. If you only need read access to customer email addresses, don't use a credential that grants write access or access to payment information.
Authentication Architecture Requirements
Route all third-party API calls through your backend. Your client application should call endpoints you control. Those endpoints authenticate to third-party services using credentials stored server-side. This pattern prevents credential exposure and gives you a single point where you can log, rate-limit, and validate all API interactions.
Validate origin and implement CORS policies. Configure Cross-Origin Resource Sharing headers to restrict which domains can call your API proxy endpoints. This won't stop a determined attacker who has already extracted credentials, but it limits casual abuse.
Use short-lived tokens where possible. When working with OAuth 2.0 or similar protocols, prefer short-lived access tokens over long-lived API keys. Configure token expiration to the shortest duration your application can tolerate.
Detection and Monitoring Requirements
Scan your repositories and deployed code. Use automated secret scanning tools to detect accidentally committed credentials in version control. GitHub, GitLab, and Bitbucket offer built-in secret scanning. Supplement with tools like TruffleHog or GitGuardian that can scan your entire commit history.
Monitor API usage patterns. Track request volumes, geographic origins, and accessed endpoints for your API credentials. Sudden spikes in usage, requests from unexpected IP ranges, or access to endpoints your application doesn't normally call indicate potential credential compromise.
Log authentication events. Maintain detailed logs of API authentication attempts, including timestamps, source IPs, and requested scopes. Retain these logs long enough to support incident investigation.
Implementation Guidance
Immediate Actions
If you're currently exposing credentials in client-side code, treat this as an active incident. Rotate the exposed credentials immediately. The credential visible in your JavaScript is already compromised the moment your page loads in any browser.
Contact your API provider to revoke the exposed credential and generate a replacement. Some providers offer emergency rotation workflows specifically for this scenario.
Review your access logs for the exposed credential period. Look for usage patterns inconsistent with your application's normal behavior. In the Manchester Airports Group incident, FulcrumSec claimed it accessed approximately 86 GB of data using exposed Iterable API credentials found in client-side JavaScript.
Architecture Migration
Refactor your application to use a server-side proxy. Create backend endpoints that accept parameters from your client application, authenticate to the third-party API using server-stored credentials, and return only the data your client needs.
This migration provides additional benefits beyond credential security. You can implement caching to reduce API costs, add request validation to prevent abuse, and transform API responses to expose only the fields your client requires.
Credential Lifecycle Management
Implement scheduled credential rotation. Set a maximum lifetime for each API credential and rotate before expiration. Document the rotation procedure and test it quarterly.
Maintain an inventory of all API credentials your organization uses, including which applications consume them, what scope they grant, and who has authority to rotate them. This inventory is essential during incident response.
Common Pitfalls
Assuming obfuscation provides security. Minifying JavaScript or encoding credentials in Base64 doesn't protect them. Browser developer tools can un-minify code, and Base64 is encoding, not encryption. If the browser can decode a value to use it, an attacker can too.
Failing to rotate after developer departures. When developers with access to credential management systems leave your organization, rotate all credentials they could have accessed. This applies to contractors, temporary staff, and employees moving to different teams.
Using the same credential across environments. Development, staging, and production should use separate API credentials. This limits the blast radius if a development credential is exposed and prevents production data from appearing in development logs or error reports.
Overlooking third-party scripts. Review JavaScript loaded from CDNs and third-party services. If a compromised or malicious script runs on your page, it can access any credentials your legitimate code uses.
Quick Reference Table
| Control | Implementation | Detection Method |
|---|---|---|
| Credential Storage | Environment variables, secret management system | Repository scans, code review |
| API Architecture | Server-side proxy for all third-party calls | Architecture review, network analysis |
| Access Scope | Minimum necessary permissions per credential | Periodic access review |
| Token Lifetime | Shortest duration application tolerates | Configuration audit |
| Usage Monitoring | Log all API requests with source IP, timestamp | SIEM alerts on anomalous patterns |
| Rotation Schedule | Maximum 90-day credential lifetime | Credential inventory audit |
| Incident Response | Documented rotation procedure, tested quarterly | Tabletop exercises |
| Code Scanning | Automated secret detection in CI/CD pipeline | Pre-commit hooks, pull request checks |
The Manchester Airports Group incident affected 8.7 million customers, with email addresses exposed for the vast majority. The breach shows that credential exposure isn't a theoretical risk. When you embed an API credential in client-side code, you're not just creating a vulnerability; you're publishing the key to your data.
Implement server-side proxies, rotate credentials regularly, and monitor usage patterns. These controls are straightforward to deploy and significantly more reliable than hoping no one inspects your JavaScript.
