Keep secrets in a managed secret store or the platform's protected connection settings, scoped to one app and rotated on a schedule. Never place them in plain text fields, formulas, scripts, shared spreadsheets or exported app files. If one is already exposed, treat it as compromised and replace it.
What goes wrong
OWASP's Authentication and Secure Communication Failures (CD-SEC-05) lists the usual faults: weak or personal credentials, secrets or tokens stored in plaintext, disabled TLS certificate validation, HTTP in place of HTTPS, missing multi-factor authentication, long-lived bearer tokens embedded in source and static credentials reused across apps and environments.
OWASP's scenario: a support manager builds an app using their personal username and password instead of a scoped API key, switches off TLS validation to avoid connection errors, and the team reuses the connection across several apps. If the password leaks, the attacker gets broad access, and traffic can be intercepted. A second scenario has an AI assistant hard-coding API keys into a script that defaults to HTTP, then copying it into a shared repository.
Where a secret may appear
| Place | Problem |
|---|---|
| Text box or variable in a flow | Visible to anyone who can edit the app |
| Formula or script | Appears in exports and copies |
| Shared spreadsheet | Broad audience, no revocation record |
| App export or template | Travels with the file |
| Screenshot or chat message | Outside every control |
| Debug log | Persists after the fact |
Safe handling in five steps
- Use the protected store. Put the key in the platform's connection or vault feature, or an external secret manager that the platform can call.
- Scope it. One credential per app, with the narrowest permissions the app needs.
- Prefer an API key or service identity over a person's password.
- Rotate. Set a date, and rotate after any staff change, export or incident.
- Keep TLS validation on. If a connection error appears, fix the certificate, not the check.
Finding exposed keys
- Search app definitions and exports for strings that look like keys or tokens.
- Review shared spreadsheets and documents attached to flows.
- Check script blocks and repositories that hold generated code.
- Look at logs for values that should not be there.
When you find one, revoke it at the source, issue a new one into the store and review what it could access in the meantime.
Policy lines to adopt
- No personal credentials in multi-user apps.
- No secrets in plain fields or exports.
- Certificate validation is never disabled in production.
- Apps with static credentials have a named owner and a rotation date.
See also is a Slack incoming webhook URL a secret for a common borderline case.
Where Safeguard fits
Safeguard does not offer secret scanning. Its dependency scanning, SBOM generation and policy gates cover the software supply chain, and the free scan at https://gold.safeguard.sh/scan shows dependency risk for a repository. Keep a dedicated secret store for credentials.
Quick check
Is a secret in a hidden field safe?
No. Hidden in the interface is not hidden from editors, exports or copies.
How often should secrets rotate?
Set a schedule you can keep, and rotate immediately after exposure or when the owner changes.
Sources
Last reviewed: 19 October 2026.
