How to Protect Secrets in JSON Config Files
Secrets do not only live in .env files. JSON configuration files -- Firebase configs, AWS credentials, Docker Compose overrides, CI/CD pipelines -- contain deeply nested API keys and passwords that most masking tools completely miss.
The Hidden Danger of JSON Configs
When developers think about secret exposure, they think about .env files. But modern applications scatter secrets across dozens of JSON files, often nested multiple levels deep. These secrets are harder to spot during a screen recording because they are buried inside structured data rather than sitting in an obvious key-value list.
Where JSON Secrets Hide
Here are the most common JSON files that contain secrets in a typical web application:
API keys, auth domains, messaging sender IDs, and app IDs. Often pasted directly from the Firebase console into source code.
NPM scripts that contain inline tokens for deployment, testing, or CI authentication. Often overlooked because package.json is "not a config file."
.NET application settings with database connection strings, JWT secrets, and third-party API keys nested under configuration sections.
Google Cloud service account keys, AWS credential files, and other provider-specific authentication files in JSON format.
Occasionally contain paths or references that reveal internal infrastructure. Not common but worth scanning.
Chrome extension and PWA manifests sometimes include API endpoints with embedded tokens in URL parameters.
The Problem with Flat-File Masking
Most secret-masking tools were designed for .env files, which have a flat structure: one key, one value, one line. JSON files are fundamentally different. Secrets can be nested 5, 7, or 10 levels deep inside objects and arrays. A tool that only masks top-level values will miss the majority of JSON secrets.
Consider a typical Firebase configuration:
"hosting": {
"public": "dist",
"headers": [{
"source": "**",
"headers": [{
"key": "X-Custom-Auth",
"value": "Bearer sk_live_abc123..." // 6 levels deep
}]
}]
}
}
A flat-file masking tool sees a valid JSON object and has no idea that the string at level 6 is a bearer token. It would need to understand secret patterns -- not just file structure -- to catch this.
Common JSON Files with Secrets
Firebase Configuration
Firebase's client configuration is routinely pasted into JavaScript source files and JSON configs. While Firebase API keys are technically not secret (they are used client-side), many developers also store Firebase Admin SDK credentials, Cloud Functions environment configs, and service account keys alongside them.
{
"type": "service_account",
"project_id": "my-production-app",
"private_key_id": "abc123def456ghi789",
"private_key": "-----BEGIN RSA PRIVATE KEY-----\nMIIEpAIBAAKCAQ...",
"client_email": "firebase-adminsdk@my-app.iam.gserviceaccount.com",
"client_id": "123456789012345678901",
"auth_uri": "https://accounts.google.com/o/oauth2/auth",
"token_uri": "https://oauth2.googleapis.com/token"
}
The private_key field contains a full RSA private key. If this appears on screen during a recording, the entire service account is compromised.
Package.json Scripts with Tokens
Developers sometimes embed tokens directly in npm scripts for convenience. This is poor practice, but it happens frequently in real-world projects:
"scripts": {
"deploy": "DEPLOY_TOKEN=ghp_abc123 npm run build && netlify deploy --auth=$DEPLOY_TOKEN",
"seed": "DATABASE_URL=postgresql://admin:p4ss@db:5432/prod node seed.js",
"test:e2e": "STRIPE_KEY=sk_test_abc123 cypress run"
}
}
Unlike .env files, package.json is always committed to version control. Secrets in npm scripts are doubly exposed: they appear in your editor AND in your repository. If you find tokens in your package.json scripts, move them to environment variables immediately.
.NET appsettings.json
.NET applications use appsettings.json for configuration. In development, this file often contains real database connection strings and API keys:
"ConnectionStrings": {
"DefaultConnection": "Server=prod-sql.database.windows.net;Database=main;User Id=admin;Password=Str0ngP@ss!;"
},
"Authentication": {
"JwtSecret": "my-super-secret-jwt-signing-key-2024",
"Google": {
"ClientId": "123456789.apps.googleusercontent.com",
"ClientSecret": "GOCSPX-abcdef123456"
}
}
}
How PixelHush Handles JSON Secrets
PixelHush parses JSON files with full structural awareness, scanning up to 10 levels of nesting. Instead of treating the file as flat text, it walks the JSON tree and applies its 48 secret-detection patterns at every level.
Pattern-Based Detection
PixelHush does not blindly mask all JSON values (which would make the file unreadable). It identifies secrets using pattern matching on both key names and value formats:
- Key-name patterns: Any key containing "secret", "password", "token", "api_key", "private_key", "auth", "credential", or similar terms
- Value-format patterns: Strings matching known API key formats (Stripe's
sk_live_, AWS'sAKIA, GitHub'sghp_, etc.) - Structural patterns: Connection strings with embedded credentials, URLs with inline passwords, base64-encoded keys
Non-sensitive values -- port numbers, hostnames, feature flags, file paths -- remain visible. This means you can still read and understand your JSON config during a recording; only the actual secrets are hidden.
Before and After
"db": {
"host": "db.internal",
"password": "s3cr3t!"
},
"stripe_key": "sk_live_51H..."
}
"db": {
"host": "db.internal",
"password": "••••••••"
},
"stripe_key": "••••••••••••"
}
Beyond JSON: All Structured Config Files
JSON is just one of the structured formats that PixelHush understands. The same deep-parsing approach applies to all 7 supported file types:
Standard environment files. Flat key-value parsing with 48 patterns for key names and value formats.
Deep nested parsing up to 10 levels. Firebase configs, package.json, appsettings.json, and any JSON config.
Docker Compose files, Kubernetes manifests, GitHub Actions workflows, CI/CD pipeline configs.
Cargo.toml (Rust), pyproject.toml (Python), Hugo configs, Netlify configuration files.
Maven settings.xml, web.config (.NET), Spring configuration, Android manifests with API keys.
Java properties files, PHP configs, legacy application settings. Key-value parsing with pattern detection.
Best Practices for JSON Secret Hygiene
Beyond screen-recording protection, these practices reduce the risk of JSON secret exposure across all vectors:
1. Never Commit Real Credentials to JSON
For files that must be committed (like package.json or firebase.json), never embed real credentials. Use environment variable references instead:
"deploy": "netlify deploy --auth=$NETLIFY_TOKEN"
// Instead of hardcoding in firebase config
const config = {
apiKey: process.env.FIREBASE_API_KEY,
authDomain: process.env.FIREBASE_AUTH_DOMAIN
}
2. Use .example Files for Onboarding
For JSON configs that are not committed, provide an example file with the structure but no real values. Name it config.example.json and document the setup in your README.
3. Leverage gitignore Patterns
Be specific in your .gitignore about which JSON files contain secrets:
credentials.json
service-account-key.json
**/appsettings.Development.json
firebase-admin-*.json
4. Scan with Pre-Commit Hooks
Use tools like TruffleHog, detect-secrets, or gitleaks as pre-commit hooks to catch JSON secrets before they reach version control. This complements PixelHush's visual protection with a code-level safety net.
If you work with REST APIs and inspect JSON responses in your browser (especially admin endpoints that return credentials, tokens, or connection details), the PixelHush Chrome Extension automatically masks secrets in JSON responses displayed in the browser, including the DevTools Network panel.
Setup: JSON Secret Protection
- Install PixelHush -- Download from pixelhush.dev. The macOS menu bar app handles screen recording detection.
- Install the editor extension -- Search "PixelHush" in VS Code, Cursor, Windsurf, or Antigravity extensions. JSON parsing is enabled by default for all
.jsonfiles. - Open any JSON config -- No configuration needed. PixelHush scans the file structure and identifies secrets using 48 patterns, up to 10 levels deep.
- Start recording or screen sharing -- The moment a screen capture begins, all detected JSON secrets are masked. Non-sensitive values remain visible for readability.
