Späť na blog
13. mája 2026

OpenAI API kľúč v hlavičkách HTTP odpovede: Nájdený za 7 minút

Viktor Bulanek
Founder & CTO, Penetrify
MSc IT Security · 20+ years in security · 4x Ex-CTO

Fakturačný panel OpenAI ukazoval poplatky, ktoré si zakladateľ nevedel vysvetliť. Aplikácia mala približne 800 používateľov na freemium modeli, ale využívanie API smerovalo k 2 000 dolárom mesačne — oveľa viac, než odôvodňovala aktivita používateľov na platforme. Zakladateľ predpokladal, že niekde majú neefektívny prompt, a poznamenal si, aby to prešetril.

Sedem minút po spustení skenu Penetrify sa dôvod objasnil: kľúč API OpenAI bol odovzdávaný späť používateľom v hlavičkách HTTP odpovedí každého proxy API volania. 800 používateľov ho videlo. Niektorí z nich ho používali.


Architektúra: Odkiaľ únik pochádzal

Aplikácia bola backend FastAPI obsluhujúci frontend React. Jej hlavnou funkcionalitou bolo proxyovanie používateľských požiadaviek na API OpenAI, pridávanie vlastných systémových promptov, ukladanie histórie konverzácií a aplikovanie vlastnej vrstvy prompt engineeringu zakladateľa. Toto je bežný vzor pre produkty obalujúce AI — hodnota nie je v modeli, ale v produkte, ktorý je okolo neho postavený.

Ako aplikácia fungovala:

  1. Používateľ odošle prompt z React frontendu
  2. Frontend ho odošle na POST /api/generate
  3. Handler FastAPI pridá systémový prompt a zavolá API OpenAI
  4. FastAPI vráti dokončenie frontendu

Niekde v implementácii trasy FastAPI bola hlavička Authorization z odchádzajúcej požiadavky OpenAI — obsahujúca kľúč API vo formáte Bearer tokenu — preposielaná späť v odpovedi. Ide o špecifickú triedu chyby preposielania hlavičiek: aplikácia preposielala hlavičky odpovedí z upstream volania API OpenAI namiesto toho, aby si vytvorila vlastné hlavičky odpovedí.

Hlavičky odpovedí pri každom volaní /api/generate zahŕňali:

HTTP/1.1 200 OK
Content-Type: application/json
Authorization: Bearer sk-proj-...[OpenAI API key]
...
{"completion": "..."}

Každý používateľ, ktorý kedy použil funkciu generovania — všetkých 800 — dostal kľúč API v hlavičkách odpovedí svojich požiadaviek. Bol viditeľný v záložke DevTools Network prehliadača, v akomkoľvek HTTP proxy a v akomkoľvek programovom klientovi, ktorý čítal hlavičky odpovedí.


Čo vám dáva kľúč API OpenAI

Kľúč API OpenAI bez obmedzení používania poskytuje držiteľovi plný prístup k API kvóte príslušného účtu. To znamená:

  • Neobmedzený prístup k modelu na náklady vlastníka kľúča — GPT-4o, o1, o3, generovanie obrázkov, embeddings, fine-tuning
  • Žiadny limit na požiadavku, kým sa nedosiahne mesačný limit výdavkov účtu
  • Prístup k akýmkoľvek fine-tuned modelom, ktoré účet vytvoril
  • Možnosť čítať uložené súbory, ak účet používa Files API

Pre individuálneho zakladateľa, ktorého aplikácia spracováva 200 – 400 dolárov mesačne v legitímnom používaní, môže zneužitie ich kľúča externe zvýšiť mesačný účet na 2 000, 5 000 dolárov alebo viac — v závislosti od toho, ako široko sa kľúč šíri a čo útočníci generujú.

Nákladový model pre zneužitie API OpenAI je asymetrický: útočník neplatí nič, vlastník kľúča platí za všetko.


Nevysvetliteľné špičky vo fakturácii, vysvetlené

Keď bolo odhalenie kľúča identifikované, špičky vo fakturácii začali dávať zmysel. Zakladateľ si stiahol panel používania OpenAI filtrovaný podľa koncového bodu a času. Vzor špičiek ukazoval vysoký objem požiadaviek, ktoré nekorelovali s aktivitou používateľov na platforme — požiadavky o 3:00 ráno, požiadavky z rozsahov IP adries, ktoré nezodpovedali žiadnej známej geografickej polohe používateľa, požiadavky na typy modelov, ktoré aplikácia nepoužívala.

Niekto extrahoval kľúč – možno niekoľko ľudí – a používal ho priamo proti OpenAI API, čím úplne obišiel aplikáciu. Požiadavky smerovali priamo na OpenAI pomocou extrahovaných poverení, nie cez aplikáciu zakladateľa.

Kľúč bol vystavený približne od prvého týždňa verejného spustenia aplikácie. V čase skenovania bol aktívny a unikal už niekoľko mesiacov.


Ďalšie zistenia

Expozícia kľúča OpenAI bola najbezprostrednejšie škodlivým zistením, ale boli nahlásené tri ďalšie problémy:

STREDNÁ — IDOR na /api/history/:userId

Aplikácia ukladala históriu konverzácií pre každého používateľa a sprístupňovala ju na predvídateľnom koncovom bode:

GET /api/history/abc123

Handler trasy načítal históriu konverzácií pre ID používateľa v parametri cesty bez kontroly, či žiadajúci používateľ vlastnil tieto záznamy. Akýkoľvek overený používateľ mohol prečítať históriu konverzácií akéhokoľvek iného používateľa nahradením ich ID. Keďže konverzácie zahŕňali používateľom zadané výzvy, išlo aj o narušenie súkromia: útočník mohol prečítať, aké otázky kládli iní používatelia nástroju AI.

STREDNÁ — Režim ladenia FastAPI povolený v produkcii

Aplikácia bežala s FastAPI(debug=True). V režime ladenia akákoľvek neošetrená výnimka vráti kompletný stack trace v HTTP odpovedi, vrátane interných ciest k súborom, verzií závislostí a názvov premenných prostredia (hoci nie ich hodnôt). Tieto informácie sú priamo užitočné pre plánovanie ďalších útokov – znalosť presnej verzie FastAPI, verzie Pydantic a verzie Pythonu výrazne zužuje zoznam použiteľných CVEs.

Režim ladenia tiež predvolene umožňuje interaktívnu dokumentáciu FastAPI na /docs a /redoc, ktorá bola prístupná v produkcii a dokumentovala každý interný API koncový bod, vrátane tých, ktoré neboli určené pre používateľský prístup.

NÍZKA — HTTP nepresmerúva na HTTPS

HTTP verzia aplikácie poskytovala plný obsah bez presmerovania na HTTPS. Vo verejných alebo zdieľaných sieťach mohol útočník vykonávajúci útok man-in-the-middle zachytiť nešifrované relácie a extrahovať tokeny relácií, používateľom zadané výzvy a API odpovede.


Oprava: Nasadená v ten istý večer

Zakladateľ nasadil opravy pre všetky zistenia do troch hodín od prijatia správy.

Najprv otočte kľúč

Pred akýmkoľvek zásahom do kódu bolo okamžitou akciou zrušiť kompromitovaný kľúč v dashboarde OpenAI a vygenerovať nový. Tým sa okamžite prerušilo akékoľvek prebiehajúce zneužívanie. Rotácia kľúčov OpenAI je okamžitá – starý kľúč prestane fungovať v momente, keď ho vymažete.

Opravte chybu preposielania hlavičiek

Hlavnou príčinou bolo, že trasa FastAPI používala generického HTTP klienta, ktorý preposielal všetky hlavičky odpovede z upstream volania OpenAI. Opravou bolo vytvoriť explicitné hlavičky odpovede namiesto preposielania upstream hlavičiek:

# Before (vulnerable) — forwarding all upstream headers
upstream_response = await client.post(
    "https://api.openai.com/v1/chat/completions",
    headers={"Authorization": f"Bearer {settings.OPENAI_API_KEY}", ...},
    json=payload
)
return Response(
    content=upstream_response.content,
    headers=dict(upstream_response.headers)  # ← this forwards the Authorization header back
)

# After (fixed) — explicit response construction
upstream_response = await client.post(
    "https://api.openai.com/v1/chat/completions",
    headers={"Authorization": f"Bearer {settings.OPENAI_API_KEY}", ...},
    json=payload
)
completion_data = upstream_response.json()
return JSONResponse(content={"completion": completion_data["choices"][0]["message"]["content"]})
# Only the data we explicitly want to return — no upstream headers forwarded

Opravte IDOR

Koncový bod histórie konverzácií bol aktualizovaný tak, aby extrahoval ID používateľa z overeného JWT namiesto z parametra cesty:

@router.get("/api/history")
async def get_history(current_user: User = Depends(get_current_user)):
    # User ID comes from the verified JWT — can't be spoofed
    history = await db.get_history(user_id=current_user.id)
    return history

Zakázať režim ladenia

# In config.py
app = FastAPI(
    debug=settings.DEBUG,  # reads from environment variable
    docs_url=None if not settings.DEBUG else "/docs",  # hide docs in production
    redoc_url=None if not settings.DEBUG else "/redoc"
)

S nastavením DEBUG=false v produkčnom prostredí interaktívna dokumentácia a podrobné chybové hlásenia okamžite zmizli pri ďalšom nasadení.


Pridanie limitov používania OpenAI ako bezpečnostnej siete

Okrem opravy úniku pridal zakladateľ dve obranné opatrenia na obmedzenie rozsahu poškodenia pri akomkoľvek budúcom odhalení kľúča:

Limity používania: Na paneli OpenAI v časti Billing → Usage limits nastavte mesačný pevný limit a prah pre mäkké upozornenie. Aj keď dôjde k opätovnému kompromitovaniu kľúča, schopnosť útočníka generovať poplatky je obmedzená.

Vyhradené kľúče pre každú službu: Vytvorte samostatný API kľúč pre každú aplikáciu alebo prostredie. Ak dôjde ku kompromitovaniu kľúča, môžete otočiť iba tento kľúč bez narušenia iných služieb a protokoly používania pre každý kľúč sú prehľadne oddelené – čo výrazne uľahčuje detekciu neoprávneného prístupu.


Ako časté je to?

Odhalenie API kľúča v HTTP odpovediach je menej časté ako odhalenie v JavaScript balíkoch, ale pravidelne ho vidíme konkrétne v aplikáciách obalujúcich AI. Tento vzor má takmer vždy rovnakú príčinu: vývojár, ktorý vytvára proxy vrstvu, používa generického HTTP klienta, ktorý preposiela hlavičky odpovedí, a nekontroluje, čo tieto hlavičky obsahujú.

Chyba pri preposielaní hlavičiek sa ľahko stane, pretože často zjednodušuje implementáciu. Prečo vytvárať novú odpoveď, keď môžete preposlať tú pôvodnú? Odpoveďou v tomto prípade je, že pôvodná odpoveď obsahuje poverenia, ktoré nechcete zdieľať so svojimi používateľmi.

Ak vaša aplikácia proxyuje volania na OpenAI, Anthropic alebo akékoľvek iné externé API, explicitne skontrolujte hlavičky vašich odpovedí. Použite nástroj ako curl -v alebo DevTools vášho prehliadača na prezeranie každej hlavičky vrátenej každým API koncovým bodom. Hlavičky sa ľahko prehliadajú práve preto, že väčšinou sú nezaujímavé – a práve to z nich robí tak účinné úkryty pre únik.


Kontext žiadosti YC

Zakladateľ v čase skenovania pripravoval žiadosť YC. Kombinácia nevysvetliteľných nárastov fakturácie, odhaleného API kľúča a zraniteľnosti IDOR ovplyvňujúcej históriu konverzácií všetkých používateľov by bola významným problémom na vysvetlenie investorom – alebo, čo je horšie, na objavenie po získaní financovania.

Bezpečnostné problémy vo fáze pred spustením alebo v počiatočnej fáze získavania používateľov sú opraviteľné v priebehu hodín. Rovnaké problémy objavené po bezpečnostnom incidente, oznámení o úniku dát alebo nepriateľskom mediálnom príbehu trvajú mesiace, kým sa z nich spoločnosť spamätá, a môžu ukončiť činnosť spoločnosti, ktorá si ešte nevybudovala dostatočnú dobrú vôľu na prežitie mediálneho cyklu.

Zakladateľ spustil Penetrify znova pred odoslaním žiadosti YC. Správa sa vrátila čistá.

Frequently Asked Questions

Aké typy zraniteľností Penetrify detekuje?

Penetrify detekuje všetky kategórie zraniteľností OWASP Top 10 vrátane SQL injection, XSS, CSRF, IDOR, nefunkčnej autentifikácie, bezpečnostných miskonfigurácií a úniku citlivých dát. Testuje tiež bezpečnosť API, správu relácií a bežné miskonfigurácie v Supabase, Firebase a Bubble.

Ako dlho trvá AI penetračný test?

Rýchle skenovanie je dokončené za 15–30 minút. Štandardné skenovanie trvá 1–2 hodiny s širším pokrytím. Hĺbkové skenovanie môže trvať niekoľko hodín pre zložité aplikácie.

Čo obsahuje správa Penetrify?

Každá správa obsahuje executive summary, celkové bezpečnostné skóre, nálezy klasifikované podľa závažnosti (Kritické, Vysoké, Stredné, Nízke), podrobné kroky pre reprodukciu a konkrétne odporúčania pre nápravu napísané pre vývojárov – nie pre špecialistov na súlad.

Related articles

CI/CD Penetration Testing: Ako integrovať bezpečnosť do každého nasadenia
Naučte sa, ako integrovať Penetration Testing do vašej CI/CD pipeline. Zahŕňa SAST, DAST, brány kvality a testovanie poháňané umelou inteligenciou bez spomalenia dodávky.
Autonómne OWASP skenovanie zraniteľností: Ako AI nahrádza bezpečnostné testovanie založené na pravidlách
Zistite, ako autonómne skenovanie zraniteľností OWASP využíva AI, aby prekonalo porovnávanie signatúr. Pokrýva OWASP Top 10 2025, agentické testovanie a prečo skenery založené na pravidlách nestačia.
Simulácia viackrokového útočného reťazca: Prečo skenovanie jednej zraniteľnosti nestačí
Zistite, ako simulácia viacstupňových útočných reťazcov odhalí zreťazené exploity, ktoré prehliadajú skenery zraniteľností. Príklady z reálneho sveta, mapovanie MITRE ATT&CK a sprievodca implementáciou.

Explore more

Compare alternatives →Security glossary →CI/CD integration →Security statistics →
Späť na blog