{ "compartment_id": "section-5", "number": "Section 5", "title_local": "The vulnerability profile of the pre-2023 API-key architecture", "title_english": "The vulnerability profile of the pre-2023 API-key architecture", "source_url": "https://phishdestroy.io/steam_dossier/#vulnerability-profile", "source_document": "index.html", "content": { "html": "
\n
\n
\nPart A — Technical record · Section 5\n

One session. More access than the user sees.

\n\n
Context & source limits

Valve's API-key architecture, as it stood before the 2023 changes, departed from baseline industry standards (OWASP ASVS, NIST SP 800-63B) and is the mechanism described in the automated inventory-theft complaints preserved in the evidence archive (Sections 6–8).

\n

The rule Valve applied: the account holder created the key, accepted the terms, and bears the loss — that is the answer in the archived refusals. The record: until December 2023 a stolen session cookie alone could register that key. No password. No Steam Guard. No notification to the person whose account it was. The user did not create the key, could not see it, and was told he did. Mobile confirmation was added on 2023-12-04 — about seven years after the 2016 statement and roughly six after the scam panels the archive preserves. Those years were not paid by Valve. They were paid by the accounts emptied in the meantime, a share of them children's.

\n
\n
\n
\n
\nOWASP ASVS 2.8 / NIST SP 800-63B\nSEVERITY: CRITICAL\n
\n

1. Insufficient Step-up Authentication

\n

\n Steam allowed the generation of highly privileged, long-lived API keys using only a session cookie. No 2FA (Steam Guard) or step-up authentication challenge was required when setting up or modifying a developer API key, so the Steam Guard mobile confirmation — the only second factor Steam offers — did not protect this step. (A hardware second factor was requested in Valve's own tracker in 2016 and the issue is still open: Appendix D, GH-01.)\n

\n
\n
\n Status: unpatched before 2023. Allowed a script holding a stolen cookie to register a key without any user interaction.\n
\n
\n
\n
\n
\nOWASP A01:2021 / Least Privilege\nSEVERITY: CRITICAL\n
\n

2. Lack of Principle of Least Privilege

\n

\n The Steam Web API lacked any role-based authorisation scopes. A developer API key issued for \"read-only\" inventory status possessed complete \"write\" permissions — including the ability to manipulate existing trades, initiate new ones, register webhooks and decline valid pending exchanges.\n

\n
\n
\n Status: systemic design defect. One key = full read/write control of the account's inventory and trades.\n
\n
\n
\n
\n
\nOWASP A07:2021 / Sessions\nSEVERITY: HIGH\n
\n

3. Broken Session Management

\n

\n Hijacked web sessions originating from server-hosting IP ranges were reported by users to persist. Standard practice is to terminate sessions on geographic anomalies and on password change; user reports collected in the archive describe sessions that remained active after a password change.\n

\n
\n
\n Status: reported behaviour (user complaints in the archive). Sessions could generate API keys without re-authentication.\n
\n
\n
\n
\n
\n
\nDomain-level blocking was technically feasible\nENFORCEMENT FEASIBILITY\n
\n

4. Domain-Level Blocking of Auth Hosts Was Technically Feasible

\n

\n Valve already operates a domain list (the Link Filter) and already receives every auth hostname in its own OpenID requests. The two mechanisms are not connected in any way visible from outside: as of 2026-09-22, in 26 pairs the main domain was on the filter while the proxy carrying its login was not.\n

\n

\n Connecting them is a small engineering task: read the openid.realm hostname from each incoming request, compare it against a list, and refuse or flag the request. The illustration on the right shows the shape of such a routine. Refusing the auth host — rather than only the public landing page — would interrupt the \"Sign in with Steam\" step that these platforms depend on.\n

\n

\n No public evidence shows that Valve runs such a check. The Steam Community Market's combined fee of about 15% applies to sales completed inside the Market; it is not collected on these platforms' external trades.\n

\n
\n
\n
\nblock_auth_hosts.py\nILLUSTRATION\n
\n
// Read the host Steam already receives — no scanning
\n
def on_openid_request(request):
\n
host = parse_openid_realm(request)
\n
if host in blocked_domains:
\n
refuse(request)
\n
\nNote: pseudocode for illustration only. Both halves already exist at Valve — the auth hostname arrives in the request, and the domain list is the Link Filter. No public record explains why they are not connected.\n
\n
\n
\n
\n
\n
\n
\nSection 5.1 — The standards were not unpublished\n

Valve builds against these rules every day. It did not build to them here.

\n

Steam ships on the App Store and Google Play, sells through the major card processors, and consumes third-party APIs like any other large platform. Each of those relationships carries a published, dated security requirement that Valve must satisfy to keep operating. Set the dates of those requirements against the dates on which Steam's own Web API acquired the same protections. Nothing below is a private standard, an internal memo or a trade secret: every row is a public document with a publication date.

\n
\n
\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
Published external security requirements, with their dates, set against the date the Steam Web API acquired the equivalent control
The published standard, and the date it took effectThe Steam Web API on the same question
Scoped authorisationOAuth 2.0 — RFC 6749, . Section 3.3 defines scope so a client receives only the access it asks for. It has been the default of every major platform API since.Granular scopes arrived on .Before that a single Steam Web API key carried full read and write over the account's trades regardless of why it was issued. Thirteen years and three months after the specification that defines the control.
A key is not an authorisationGoogle's own Cloud documentation: A standard API key doesn't authenticate a principal, and for APIs that create or manage resources, don't use authorization keys in production.The Steam Web API key was exactly that.A bearer string, issued to an account, sufficient on its own to read the inventory, cancel a pending trade and send a new one. No principal was authenticated at the point of use.
Multi-factor authentication on privileged accessPCI DSS 3.2, requirement 8.3 — mandatory from for all non-console administrative and all remote access to the cardholder data environment. Apple then required two-factor authentication of every Developer Program account holder from : developers with the Account Holder role in a developer program will need to enable two-factor authentication to sign in.A second factor was required to create an API key from .Until then a stolen session cookie was enough, with no prompt on the account holder's phone and no notification afterwards. Four years and nine months after Apple made Valve itself use a second factor merely to sign in to a developer portal.
Credential lifecycle and revocationTwitch requires of every third-party application: Your app must validate the OAuth token when it starts and on an hourly basis thereafter, and states that it audits for applications that do not. Its legacy v5 API was retired outright on on a published schedule.No published key-lifecycle record.The 2023 change protected the creation endpoint. No Valve statement located with it addresses keys already registered, and no changelog accompanied the change at all. Whether keys created before it were invalidated cannot be established from public data — which is the question a data subject would need answered to know whether a key created on their account years earlier is still live.
\n
\n
\n
\n
\nArchitectural Benchmark // Token Architecture\n

GitHub Fine-Grained Scopes vs Valve Steam Web API

\n

Valve developers manage open-source software on GitHub daily using granular least-privilege tokens. Compare that with the monolithic key issued to 130M Steam players.

\n
\n\n
\n
\n\n
\n
\n
\n
\n\nGitHub Fine-Grained Token\n
\nUsed by Valve on GitHub\n
\n

Fine-grained token with scoped isolation and mandatory lifecycle enforcement.

\n
\n
\nRepository Access:\nSelected Repos only (1 repo)\n
\n
\nIssue Permissions:\nRead-only [✓]\n
\n
\nCode & Secrets:\nNo access [✕]\n
\n
\nExpiration:\n30 Days (Mandatory TTL)\n
\n
\nAudit Logging:\nIP, User-Agent & Timestamp\n
\n
\n
\n
\nSecurity Posture: Least-privilege token limits damage to a single read-only resource.\n
\n
\n\n
\n
\n
\n
\n!\nValve Steam Web API Key\n
\nIssued to 130M Users\n
\n

Single 32-character master string carrying all-or-nothing trade and inventory authority.

\n
\n
\nAccount Access:\nFULL ACCOUNT (Monolithic)\n
\n
\nTrade Management:\nRead, Cancel, Decline [!]\n
\n
\nGranular Scopes:\nNONE (Arrived 2026, 13y late)\n
\n
\nExpiration:\nNEVER (Valid indefinitely)\n
\n
\nAudit Logging:\nNONE (Zero IP history for user)\n
\n
\n
\n
\nVulnerability: Stolen key allows silent interception of all outgoing trade offers.\n
\n
\n
\n
\n
\nThe standard applied in one direction\n

Suppose a vendor Valve depends on — a cloud provider, a payment processor, a CDN — left a credential endpoint without a second factor, and months later Valve's own corporate data left through a key minted at that endpoint. Would Valve accept that the fault lay with whoever clicked the link? The archived refusals preserved in this dossier answer the mirror-image question for the user: the position taken is that the account holder created the key and bears the loss. The same architecture is described as the vendor's failure in one direction and the user's responsibility in the other. Which it is, is not a technical question, and it is not one this investigation can settle — it is what a court or a supervisory authority decides.

\n
\n
\nIllustration, not evidence — the standard read back the other way\n
    \n
  • A payment processor that let a third-party script mint a full-privilege transaction credential from a browser cookie alone, with no prompt to the account holder.
    • \n
  • An identity provider that closed the hole its tokens were minted through and published nothing about the tokens already minted.
    • \n
  • A bank that answered a disputed transfer by observing that the credential used was registered on the customer's own account, and closed the ticket.
    • \n
\n

None of these is offered as a finding about any named company. They are the same design decisions, moved to a setting where the supervisory response is well documented — which is the comparison a regulator is being asked to make.

\n
\n

What the record establishes: the controls absent from the Steam Web API were public, dated and, in several cases, conditions Valve had to satisfy to keep shipping its own products. The interval between each standard and the equivalent Steam change is measurable and is set out above. What it does not establish is why. No Valve statement of reasons for any of these intervals has been located, and none is assumed here; that record exists inside Valve and has not been published.

\n

Sources, each a public document: OAuth 2.0 — RFC 6749, October 2012 ↗ · Google Cloud — API keys documentation ↗ · PCI DSS 3.2 requirement 8.3 — PCI SSC resource guide ↗ · Apple — Upcoming Two-Factor Authentication Requirement for Account Holders, 20 February 2019 ↗ archived 2025-05-06 ↗ · Twitch — token validation requirement ↗ and the v5 shutdown notice ↗ archived 2025-01-27 ↗. Steam's own dates are those in the update record in this section; the 2023 and 2026 entries are the ones Valve shipped without a changelog. Retrieved 2026-09-22.

\n
\n
\n
\n
\nValve's own update record — dated, from public sources\n
\n
\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
DateValve changeAnnounced?What it closedLag: mechanism public → fixSource
2026-09-01Automated Suspicious Chat FlaggingYesDangerous links / patterns in group chats—news ↗
2026-01-16Steamworks Web API granular scopesYesLeast-privilege scopes for developer keys—announcement ↗
2025-07-15CS2 Trade Protection & reversal windowYesNothing. Not a root-cause security fix. Support-side account recovery access remains untouched. Triggering reversal inflicts an automatic 30-day trade lockout (Skinvault ↗), while cash-trading shock caused a $104M (-25%) 24h market cap plunge (CSMarketCap ↗). In 2026, timers became per-item (Skin.land ↗).—FAQ ↗
2025-05-14Account Security AnnouncementYesStealer / session-hijack guidance—announcement ↗
2024-10-02CS2 'The Armory' 7-day holdYesHold on trade/market for Armory items—announcement ↗
2024-09-18New-device login trade restrictionYes2–7 day trade lock on new devices—FAQ ↗
2024-02-14Profile name & avatar change holdYes2–4 h cooldown on trades after rename—post ↗
2023-12-04Mobile confirmation for API keysNo changelogSilent cookie-only key registration≈6 years after the 2017-era panelsdev page ↗
2023-10-24SMS MFA for game build publicationsYesSteamworks build publishing—announcement ↗
2023-07-12Custom biography content warningYesPhishing links in bios—forum ↗
2023-01-25Profile {LINK REMOVED} & cooldownYesLinks in profile text—FAQ ↗
2022-10-24Login overhaul & cookie truncationNo changelogInfinite stolen sessions— (IAuthenticationService token migration)news ↗
2022-10-12Mobile App 3.0 QR loginYesSession deauthorisation panel—news ↗
2022-05-10Trade-cancellation endpoints removedNo changelogOffer-swap (cancel & re-send)≈5 years after the 2017-era panelsissue #325 ↗
2020-05-25Dota 2 7-day trade lockYesFast item flipping—blog ↗
2018-03-29CS:GO 7-day trade lockYesInstant bot laundering≈20 months after the July 2016 statementblog ↗ archived 2025-02-26 ↗
\n
\n
Sources: the linked Valve posts, help pages and GitHub issues, as dated. Three decisive fixes shipped with no changelog (2022-05, 2022-10, 2023-12) and were detected by users, not announced by Valve — that asymmetry is part of the enforcement record. Lags are computed only where the dossier's own dating (July 2016 statement; 2017-era scam panels) supplies the start point; \"—\" means no such start point is established here.
\n
\n
" }, "original_content_sha256": "c94c57c5acfb5ce5d1b9edb1a23abdf39d4e5ded7f6a9bf3b1860ec1d3351cd3", "author_pseudonym": "Agent Sofia", "schema": "phishdestroy.macro-fact.v1", "language": "en", "aggregator": "PhishDestroy", "exports": { "pdf": "/steam_dossier/exports/agent-protocol/files/en/steam_dossier_section_5_agent_sofia.pdf", "json": "/steam_dossier/exports/agent-protocol/files/en/steam_dossier_section_5_agent_sofia.json", "signature": "/steam_dossier/exports/agent-protocol/files/en/steam_dossier_section_5_agent_sofia.json.asc" }, "integrity": { "signed_object": "steam_dossier_section_5_agent_sofia.json", "signature_file": "steam_dossier_section_5_agent_sofia.json.asc", "signing_key_fingerprint": "129FC7F39C40C69D2EF3C329BFCF9E8DD295EE01", "scope": "Exact JSON bytes, including macro-fact author and corresponding PDF SHA-256. PhishDestroy is the integrity signer; original evidence attribution is unchanged." }, "pdf": { "filename": "steam_dossier_section_5_agent_sofia.pdf", "sha256": "d34793bba0a023c8f8b6069a479c781e553d56478ad51bca4541ee1a1de3fadd", "pages": 8 } }