Often yes. Staging and test services frequently call real vendor accounts with real credentials, and sometimes real customer data. Check by listing outbound destinations and credentials per environment, then move each integration to a vendor sandbox or a mock, and record the environment in your inventory.
Why this matters
OWASP's inventory guidance says to avoid using production data with non-production API deployments, and that if this is unavoidable those endpoints need the same security treatment as production. It also describes how a beta host running the same API without the protection of the main one let a researcher in. Third-party integrations in staging create a version of the same problem: weaker controls around a path that reaches real accounts.
How to check
- Add an environment column. One row per integration per environment, or a field listing which environments call it.
- Compare hostnames. If staging and production call the same vendor hostname with no sandbox variant, ask why.
- Compare credentials. Check whether staging holds the same key name or value as production. Look in the secrets manager entries, by name and owner, not by exposing values.
- Check the data. Look at what staging databases contain. If they hold copies of production data, every integration in staging may be sending real information out.
- Look at side effects. A staging test that sends real emails, charges real cards or posts to real channels is the sharpest symptom.
Options for each integration
| Option | When it fits |
|---|---|
| Vendor sandbox account | The vendor offers one with realistic behavior |
| Mock server | You need predictable responses and no vendor traffic |
| Recorded responses | Contract-style tests where replay is enough |
| Separate account with limits | No sandbox exists, so cap and monitor it |
| Disabled in non-production | The feature is not needed for testing |
Rules of thumb
- Never share one credential across environments.
- Give non-production accounts the lowest scope and spend limits the vendor allows.
- Use synthetic or masked data in test, and keep it that way.
- Block outbound traffic from non-production to production vendor accounts where you can identify them.
- Record the sandbox in the inventory row, with its own owner and credential location.
What to do about existing data
If staging has held real data in the past, involve privacy before you make claims about what vendors received. A data flow map for non-production environments will show which vendors may have seen it.
Make it stick
Add a pull request check or review question: does this change add an integration to a non-production environment, and which account does it use? Review the list each quarter with the rest of the inventory.
Try it yourself
The demo below shows an API security scan. Run through it and think about which environment you would point it at, and whether that target uses real vendor credentials.
Click through it at your own pace, or open it full screen.
Quick check
Is a mock server enough for testing?
For many cases yes, but keep some contract checks against the vendor sandbox, since mocks drift from the real API.
What if the vendor has no sandbox?
Use a separate low-scope account with limits, mock the calls, or disable the feature outside production.
Safeguard offers SBOM and dependency scanning and asset discovery that can feed this kind of inventory. You can run a free scan at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
