tl;dr I scanned 1,225,736 public DotNetFiddle snippets with TruffleHog and found 140 verified live secrets. A separate context-aware pass found a live HMAC key used for Zendesk SSO. It was not present in the verified results, even though the key could be used to sign an SSO token for any user.
Truffle Security's [earlier research](https://trufflesecurity.com/blog/thousands-live-secrets-found-across-four-cloud-dev-environments) scanned four JavaScript playgrounds and found 8,792 verified secrets. DotNetFiddle was not included.
Those JavaScript playgrounds mostly exposed frontend and SaaS credentials. DotNetFiddle produced a different set of results: Azure, SQL Server, Office 365, SharePoint, and other services commonly used in .NET environments.
It also exposed a limitation in verification-based secret scanning. Some high-impact secrets have no fixed format and no provider that a scanner can contact to check whether they are live. Those secrets require context from the surrounding code.
What is DotNetFiddle?
DotNetFiddle is the .NET version of JSFiddle. Developers can write C#, VB, or F#, run it on the server, and share the result through a public URL.
Like the other playgrounds in the earlier research, DotNetFiddle has no secret scanning or push protection. When credentials are pasted into a saved fiddle, they remain public until someone removes them.
The Token That Started the Research
In June 2025, a live, MFA-cleared Microsoft Graph token appeared in a public DotNetFiddle snippet, issued by Microsoft's own corporate tenant, with read/write scopes across mail, OneDrive, SharePoint, and Intune.
Someone was testing a C# snippet and needed a working credential, so they grabbed the access token from their Graph Explorer session and pasted it in.
Graph tokens last about ninety minutes, so when my scan reached it more than a year later, it was long since invalidated.
I mention it because you can read a token without using it. Decode the JWT; the tenant, scopes, and MFA claim are all in plaintext. It isn’t one of the 140 verified secrets I discuss later on, it's just what got me looking at DotNetFiddle.
Discovering Public Fiddles
DotNetFiddle's search page uses an endpoint that returns the full public listing when given a sufficiently large page size. I did not need to guess fiddle IDs. The endpoint produced a queue of 1,233,240 public fiddles, each with its language, project type, compiler, author, and timestamps.
The fetcher saved its progress while running, so a crash resulted in the loss of only the batch being processed. It also distinguished between two failure cases:
* A request blocked because of its source IP, which needed to be retried.
* A fiddle that returned a genuine 404 or had been deleted.
Anything still missing after the first pass entered a retry loop. The loop continued until no retriable items remained.
Cloudflare regularly throttled requests, and proxies kept failing. The retry process took several passes, and collecting the corpus took days.
The final dataset contained 1,225,736 fiddles, or 99.39 percent of the original queue, and occupied about 5.6 GB. The remaining 7,504 entries were empty or deleted.
Scanning With TruffleHog
I scanned the downloaded corpus with TruffleHog and found 140 verified live secrets.
Most of the results involved Microsoft enterprise services. Credentials for Azure Blob Storage, Azure SQL, Cosmos DB, and Azure AD appeared most often.
My own .NET-tuned regex pass produced 9,702 raw hits, including the following:
307 ADO.NET connection strings
33 SharePoint tenant URLs
19 Azure AD login endpoints
18 Office 365 SMTP blocks
8 ServiceNow tenants
The type of credential varied with the platform. The JavaScript playgrounds contained more frontend and SaaS credentials. DotNetFiddle contained more Azure and enterprise credentials used by .NET developers.
What Verification Does Not Detect
Most of TruffleHog’s 800-odd detectors look for something recognizable, such as a prefix like `AKIA...` or `ghp_`, or a known service endpoint. The detector can then contact the provider to check whether the credential is live.
That process does not work when a secret has no recognizable format and no provider endpoint available for verification.
Symmetric JWT signing keys are one example. An application using HMAC-signed JWTs signs each token with a shared secret. Anyone who obtains that secret can create a valid token impersonating any user, including an administrator, and the application will accept it.
The key itself has no required prefix or format. It is simply a high-entropy string. There is also no provider API available for verification because the application checks the signature locally.
What the key does have is context. Elsewhere in the same file, there may be a signing call, a symmetric algorithm such as `HS256`, and a literal key passed into the function. Those elements may be spread across the file, so a line-by-line regex does not connect them.
I wrote a detector that collects those elements from anywhere in a file and checks whether they form a complete signing flow.
A Zendesk SSO Signing Key
The context-aware detector found a live HMAC secret used to authenticate Zendesk SSO logins in a production environment.
Anyone with the key could sign an SSO token for any user and authenticate to the company's support platform without a password.
My original regex pass had already matched the value, but only as a variable containing an API-key-shaped string. During manual review, I labelled it as a token and moved on. Nothing in that workflow distinguished a symmetric signing key from a generic high-entropy value, so it remained in the wrong category after human review.
Correctly identifying it required reading the key alongside the signing call and the `HS256` algorithm.
The 140 verified findings cover secret types that TruffleHog could detect and verify. They do not include context-only findings such as this signing key, OAuth client ID and secret pairs, or other SSO shared secrets.
Comparing the Two Methods
My regex rules matched about 10,000 fiddles. Most of the results were not useful: `password = "password"`, variables pointing to configuration files that were not included in the snippet, and similar examples.
I grouped the matches by how promising they appeared, manually reviewed the strongest candidates, and retained 192 results.
At the fiddle level, the datasets compared as follows:
39 appeared in both datasets.
94 appeared only in TruffleHog's results. These were mostly verified vendor credentials that my rules did not target.
153 appeared only in my results. These were mostly connection strings, Office 365 logins, plain tokens, OAuth client ID–client secret pairs, and the Zendesk SSO signing key.
Other Notable Findings
24 live Azure credentials: storage account keys, AD service-principal secrets, Cosmos DB keys, and a SAS token. Several look like real corporate tenants rather than personal sandboxes.
11 live GitHub tokens and 10 live AWS keys, sitting in throwaway demos.
A live Anthropic API key, from someone testing an LLM call.
15 live Mailgun and 7 live SendGrid keys, both useful for sending mail as the victim.
One of the hundreds of connection strings contained a live SQL Server credential, providing direct database access with no API in the way.
Disclosure and Remediation
TBC
Takeaways
For developers: A saved fiddle is a public document. Deleting it later does not help if a scanner collected it while it was available. Rotate the secret, not the fiddle.
For platforms: Researchers have now checked five playgrounds, and every one contained live credentials. None had controls to prevent secrets from being saved publicly. Secret scanning at save time is not only relevant to JavaScript platforms.
For scanner authors: Matching recognizable formats and verifying them with providers does not detect every high-impact secret. Some credentials can only be identified by examining how the surrounding code uses them.
For researchers: Scanning only the largest platforms does not cover every development community. Different languages are used with different services, and their playgrounds expose different types of credentials. Other languages and playgrounds have not yet received the same attention.
