Bronnen · 37
Beveilig een GraphQL API: autorisatie, querykosten en bewijs
Handhaaf object- en veldrechten, beperk serverwerk en test weigeringspaden.
Bijgewerkt · 2 min
Wat deze handleiding helpt bereiken
- Het blootgestelde schema in kaart brengen
- Machtigingen oefenen
- Kosten van gebonden query's
- Weigeringen verifiëren
Snelle controle
- Kan een account een object van een ander account lezen?
- Volgt een gevoelig veld de toegangsbeslissing van het bovenliggende account?
- Wat zijn de gezamenlijke kosten van diepte, aliassen en paginering?
- Welke details lekken door fouten heen?
- Wie observeert weigeringen en misbruik?
Stapsgewijze methode
- 1
Inventariseer bewerkingen
Lijst typen, velden, mutaties, rollen, objecteigenaren en gevoelige gegevens. Inclusief huidige clientquery's en zelden gebruikte paden.
Resultaat: matrix van bewerkingen, rollen, objecten en velden.
- 2
Test elke toegangsbeslissing
Maak afzonderlijke testaccounts aan en wissel object-ID's, inclusief geneste objecten. Resolvers moeten autorisatie afdwingen voordat ze gegevens retourneren.
Resultaat: reproduceerbare toegestane en geweigerde gevallen.
- 3
Werking van de gebonden server
Meet de werkelijke kosten van velden en verzamelingen. Test diepte, breedte, aliassen, paginering, batchverwerking en tijd samen en stel vervolgens geschikte limieten in.
Resultaat: kostenbeleid en set van vijandige query's.
- 4
Verminder onnodige blootstelling
Bepaal introspectie voor de context, verberg interne foutdetails en verwijder velden die meer onthullen dan nodig is voor de clients.
Resultaat: beoordeelde openbare configuratie en foutreacties.
- 5
Observeer met terughoudendheid
Registreer nuttige technische identiteit, bewerking, kosten, weigering en correlatie, met uitzondering van geheimen en gevoelige argumenten. Wijs eigenaarschap van waarschuwingen toe.
Resultaat: dashboard en onderzoeksprocedure.
- 6
Herhalen na wijziging
Wanneer een veld, rol of client verandert, herhaal autorisatie- en laadgevallen. Controleer oude query's die nu de herziene grafiek doorlopen.
Resultaat: regressietest en releasebeslissing.
Managementindicatoren
| Indicator | Wat het meet | Eerste actie |
|---|---|---|
| Toegang | Object- en veldgevallen geweigerd zoals verwacht | Repareer de resolver |
| Kosten | Zware query's beperkt door beleid | Pas velden en limieten aan |
| Fouten | Openbare reacties zonder interne details | Verminder de weergegeven details |
| Regressie | Clientbewerkingen worden na een wijziging opnieuw afgespeeld | Blokkeer onbedoelde fouten |
Veelvoorkomende fouten
- Vertrouw alleen op toegang tot eindpunten
- Beperk de diepte, maar negeer de breedte
- Vergeet autorisatie voor geneste velden
- Log argumenten met gevoelige gegevens
Veelgestelde vragen
Verwijdert GraphQL de gewone API-autorisatie?
Nee. Elke toegang tot een object en veld vereist nog steeds een op identiteit en context gebaseerde beslissing.
Is het uitschakelen van introspectie voldoende?
Nee. Het kan de blootstelling van het schema verminderen, maar lost de toegangs- of querykosten niet op.
Is een dieptelimiet voldoende?
Nee. Aliassen, breedte, lijsten en veldspecifieke kosten zijn ook van belang.
Officiële referenties
Referenties ondersteunen de methode. Pas controles aan uw context aan; ze zijn geen certificering. Originele referentietitels en brondocumenten kunnen in een andere taal zijn.
