TL;DR
These prompts help you secure configuration files by separating secrets from non-sensitive config, adding validation, preventing accidental commits, and ensuring proper access controls. Keep your config clean and your secrets safe.
Audit and Secure Config Files
Use this prompt to audit every configuration file in your project for hardcoded secrets. Your AI will separate sensitive values into environment variables, create a validation schema for startup checks, and generate documentation for required vs optional config.
Config Security Audit
Audit my configuration files for security issues.
Find and review:
- All config files (*.config.js, *.json, *.yaml, *.toml)
- Any hardcoded secrets in configuration
- Configuration that should vary by environment
For each config file:
- Identify any sensitive values that should be env vars
- Check if the file is in .gitignore (if it should be)
- Suggest a separation between public config and secrets
Create:
- A public config file (can be committed) with non-sensitive defaults
- Environment variable references for all secrets
- A config validation schema to catch missing values at startup
- Documentation of required vs optional configuration
Framework-Specific Config Security
Next.js Configuration
Copy this prompt to secure your Next.js configuration files. Your AI will audit next.config.js, ensure no secrets leak through publicRuntimeConfig, create a typed config loader, and add build-time validation for missing environment variables.
Next.js Config Security
Secure my Next.js configuration files.
Review and fix:
- next.config.js - ensure no secrets are exposed
- Check for secrets in publicRuntimeConfig (exposed to client!)
- Verify serverRuntimeConfig is used for server-only secrets
- Audit any custom config files
Create:
- A secure config/index.ts that loads env vars
- Proper separation of client-safe vs server-only config
- Validation that fails at build time if config is missing
- TypeScript types for all configuration values
Make sure NEXT_PUBLIC_ vars don't contain anything secret.
Node.js Config
Use this prompt to create a secure configuration system that cleanly separates secrets from non-sensitive settings. Your AI will set up environment-aware config merging, type checking, and fail-fast validation with clear error messages.
Node.js Config Security
Create a secure configuration system for my Node.js application.
Requirements:
- Separate config from secrets completely
- Use environment variables for all secrets
- Allow config files for non-sensitive settings
- Support different environments (dev, staging, prod)
- Validate all config at startup
Structure:
- config/default.js (non-sensitive defaults, committed)
- config/env.js (environment overrides, committed)
- .env files (secrets, NOT committed)
The system should:
- Merge config files with env var overrides
- Type-check configuration values
- Fail fast with clear errors for missing required values
- Never log sensitive values
Config Validation
This prompt asks your AI to build a Zod-based configuration validation system that runs at startup. You'll get typed schemas for database, auth, API, and feature flag settings, with clear error messages when required values are missing.
Config Validation Schema
Create a configuration validation system using Zod (or similar).
For my project's configuration:
- Define a schema for all config values
- Include types (string, number, boolean, url, email)
- Mark which values are required vs optional
- Add default values where appropriate
- Include custom validation (valid URLs, proper formats)
The validation should:
- Run at application startup
- Provide clear error messages for missing/invalid values
- Transform values where needed (string to number)
- Export typed configuration object
Example config structure:
- Database: URL, pool size, SSL mode
- Auth: JWT secret, session duration, OAuth credentials
- API: rate limits, timeouts, external service URLs
- Features: feature flags and toggles
Never commit config files with real secrets: Even if you plan to change them later, secrets in git history can be extracted. Use .env files and .gitignore from the start.
Prevent Config Exposure
Copy this prompt to lock down configuration files from web access and accidental exposure. Your AI will check for publicly accessible .env and config.json files, add server rules to block them, and audit error messages and source maps for leaked config values.
Config Exposure Prevention
Help me prevent configuration files from being exposed.
Check for:
- Config files accessible via web (/.env, /config.json)
- Source maps that might expose config
- Error messages that leak configuration
- API endpoints that return config values
Implement:
- Proper .gitignore for all sensitive config
- Server rules to block access to config files
- Error handling that doesn't expose secrets
- Audit logging for config access
For deployment platforms:
- Vercel: check vercel.json for exposed routes
- Netlify: review _redirects and _headers
- AWS: check S3 bucket policies
Pro tip: Use a config management tool or library like convict (Node.js) or dynaconf (Python) that enforces validation and makes it easy to separate secrets from config.
Should config files ever be committed to git?
Non-sensitive configuration (feature flags, timeouts, public URLs) can be committed. Anything containing secrets, credentials, or API keys should never be committed.
How do I handle config for different environments?
Use environment variables that differ per deployment, combined with committed base config files. Never commit environment-specific secrets.
What's the difference between config and secrets?
Config is non-sensitive settings (timeouts, feature flags, public URLs). Secrets are credentials, API keys, and anything that would cause harm if exposed.
Audit Your Config Files
Scan your repository to find exposed configuration and secrets.