Handling Secrets and Keys in Web3 Backends

Web3 backends often hold sensitive secrets: RPC provider keys, admin tokens, database credentials, webhook secrets and sometimes private keys for wallets that sign transactions automatically. A leaked secret can lead to anything from an expensive API bill to a drained hot wallet. Careful secret handling is a core part of building crypto products.

Types of secrets

Secret	Risk if leaked
RPC or API provider keys	Quota theft, unexpected costs
Admin tokens	Unauthorised access to admin actions
Database credentials	Data theft or tampering
Webhook signing secrets	Forged notifications
Hot wallet private keys	Direct loss of funds
Deployment credentials	Malicious code deployed to production

Rank secrets by impact and protect the most dangerous ones most carefully.

Never put secrets in code

The most common leak is committing secrets to repositories. Prevent it:

1. Store secrets in environment variables or a secret manager
2. Add secret files to gitignore from the start
3. Use secret scanning tools in repositories and continuous integration
4. Never expose server secrets in frontend bundles
5. Treat any secret committed to a repository as compromised, even if deleted later

Public repositories are scanned by bots within minutes. Private repositories leak too, through forks, contractors and compromised accounts.

Use least privilege

Each secret should grant only the access its job needs:

• API tokens scoped to specific resources and actions
• Separate credentials for development, staging and production
• Database users with only required permissions
• Admin tokens that cannot perform unrelated operations

When a scoped secret leaks, the damage is limited.

Hot wallets need special care

Backends that sign transactions automatically, such as relayers, payout systems or bots, hold hot wallet keys. Reduce risk:

• Keep hot wallet balances small and top them up from a secure treasury
• Use separate hot wallets for separate functions
• Set spending limits in smart contracts or policy engines where possible
• Monitor hot wallet transactions and alert on anything unusual
• Consider managed key services or hardware security modules for higher value operations

Many systems do not need hot wallets at all. Payment detection, for example, only reads public chain data, so no private key needs to exist on the server.

Rotate and revoke

Rotation limits the life of a leaked secret:

• Rotate secrets on a schedule
• Rotate immediately when team members with access leave
• Revoke unused tokens
• Keep an inventory of secrets, where they are used and who can access them

Design systems so rotating a secret does not require downtime.

Protect deployment pipelines

Deployment credentials are high-value targets. Limit who can deploy, protect continuous integration secrets, require reviews for production changes and monitor deployments for unexpected activity.

Logging without leaking

Logs often capture secrets accidentally. Avoid logging request headers containing tokens, full environment variables or signed payloads. Redact sensitive fields before logs leave the application.

Prepare for incidents

Write a short plan for secret leaks: how to revoke, rotate, check logs for misuse and communicate if users are affected. Practise the plan before you need it.

Read-only by design

The safest secret is one that does not exist. Proud Globe detects payments using only public blockchain data, so its servers never hold a private key for the receiving wallet. The only server secret is an admin token, stored as a platform secret and never shipped to the browser. You can see the result on any order page, which verifies payments without touching a key.