GraphQL er ikke ment å bli eksponert over internett

Hei Verden! Jeg heter S og jeg er vekstsjef her i Wundergraph. Artikkelen er skrevet av vår administrerende direktør / CTO Jens Neuse. Nyt!

GraphQL er for tiden en av de mest nevnte teknologiene når det kommer til innovasjon i API-økonomien. Adoptører nyter brukervennligheten og verktøyene som for eksempel GraphiQL, det nettleserbaserte brukergrensesnittet for å prøve ut hvilken som helst GraphQL API. Hele opplevelsen av GraphQL er akkurat det frontend-utviklere trenger for å bygge fantastiske interaktive nettapplikasjoner.

Men med økningen av adopsjon begynner jeg å bli mer og mer bekymret for måten folk forstår GraphQL og bruker den på. I dette innlegget vil jeg gjerne dele min upopulære mening om hva GraphQL egentlig er ment å være og hvorfor du bør være bekymret hvis du bruker den på den populære, men risikofylte måten.

API-stiler

La oss ta et skritt tilbake og diskutere APIer og API-stiler generelt før vi svarer på hovedspørsmålet om hvorfor du sannsynligvis bruker GraphQL på feil måte.

APIer tilbyr en måte å skjule kompleksiteten til implementeringen bak et brukervennlig grensesnitt. For eksempel kan en handlekurv ha metoder for å legge til og slette varer eller for å gå videre til kassen. Som bruker av denne handlekurv-API-en trenger du ikke tenke på hvordan dataene blir lagret eller hva som skjer når du legger til eller fjerner en vare.

I løpet av de siste tiårene har forskjellige stiler av APIer dukket opp, alle med forskjellige implementeringer, avhengig av brukstilfellene.

Du trenger sannsynligvis ikke GraphQL

Hvis du ønsker å velge riktig API-stil for et problem, må du også vurdere hvordan API-en blir publisert og brukt. Kjenner du alle brukerne og brukssakene dine? Er disse brukerne en del av din egen organisasjon? Er de partnere? Svarene vil mest sannsynlig påvirke ditt valg av API-stil og implementering, ikke sant?

Den siste setningen er der jeg tror vi tar feil mye av tiden. Jeg ser folk over alt velger API-stilen og implementeringen lenge før de viktige spørsmålene ble besvart.

Har du problemer med Facebook-vekt?

Det nåværende mest populære eksemplet på denne oppførselen er GraphQL. Bygger du en moderne enkeltsideapplikasjon med React? Fantastisk, bruk GraphQL! Facebook, Airbnb, Paypal, Netflix, de gjør det alle sammen, så det må passe godt.

Hvorfor ser vi ikke flere diskusjoner rundt valg av riktig teknologi for et gitt problem? Jeg antar at det er mangel på utdanning, men jeg er ikke sikker på dette. Hvis du har en relevant grad, kan du svare på dette med din erfaring med utdanning på APIer.

Husk alltid at hvis du bruker Facebook-skalaverktøy uten å ha en Facebook-skala-organisasjon og Facebook-skalaproblemer, kan du smertelig innse at du bruker en slegge for å knekke en nøtt. Det er den samme grunnen til at kaosmonkey er fornuftig for Netflix mens det ikke gjør det for de to docker-containerne dine som kjører på en 5$-maskin på digital hav.

Hvorfor blir GraphQL så populær?

GraphQL forenkler kommunikasjonen mellom API-utvikler og API-forbruker. API-forbrukere, ofte frontend-utviklere, får mange endringsforespørsler fra produkteiere som fører til endrede krav til API. Med GraphQL har du en god sjanse til å ikke bli tvunget til å snakke med utvikleren av API. Du endrer spørringen og kan gå tilbake til CSS og Javascript.

Jeg antar at dette var en av hoveddriverne på GitHub for å velge GraphQL som en implementering av den spørringsbaserte API-stilen for deres nye API. API-en deres er offentlig tilgjengelig. De har et stort antall API-forbrukere, alle med forskjellige krav. De kan ikke bygge ressursbaserte APIer som tilfredsstiller alle brukerne deres. I denne spesielle brukssaken kan GraphQL faktisk være et godt valg. I stedet for å prøve å løse hvert problem, tilbyr de heller en generisk GraphQL API.

Du er sannsynligvis ikke GitHub, er du?

Hva er avveiningene som GitHub er villig til å akseptere når offentlig avsløre en GraphQL API? De har et helt team bak deres GraphQL API, og sørger for at du, brukeren, ikke ødelegger systemene deres ved et uhell eller med vilje. Du kan se videoer av dem som snakker på konferanser om de komplekse systemene de bygde for å sikre deres API og holde det stabilt. De har bygget verktøy for GraphQL-spesifikk analyse for å få bedre innsikt i API-bruk.

Forstår du risikoen fullt ut?

Jeg antar at mange utviklere med fokus utenfor sikkerhet har liten erfaring med hva som skal til for å sikre en REST API eksponert på internett. De fleste av oss har liten erfaring med å implementere autentisering, autorisasjon, ratebegrensning osv. . Imidlertid tror jeg det er ganske enkelt å sikre en RESTful API, sammenlignet med en GraphQL API. Ethvert HTTP-basert API-rammeverk lar deg definere rutene dine og legge til standardiserte mellomvare for å løse problemene som er oppført ovenfor. Et enkelt HTTP-kall tilsvarer alltid et enkelt kall på kontrolleren til en API. Med GraphQL på den annen side, kan en enkelt spørring resultere i tusenvis av anrop til kontrollerene (løsere) til API. Det er ingen enkel måte å løse dette problemet på.

Avhengig av språket du bruker, prøver ulike biblioteker å hjelpe deg med problemet. Hvor tillitsfulle er disse bibliotekene? Forstår du fullt ut hvordan de fungerer? Er det kantsaker vi ennå ikke er fullt klar over?

Vil du ha like mye nytte som GitHub?

Er du en enkelt utvikler som jobber med et sideprosjekt? Har du så mye nytte av å bruke GraphQL som du forventer? Bruker du mange forskjellige klienter med forskjellige databehov? Trenger du virkelig et spørringsbasert API? Hva er din strategi for å bekjempe problemene som er oppført ovenfor?

Men jeg viser ikke GraphQL API

Du tenker kanskje at GraphQL-API-en din egentlig ikke er eksponert. Den brukes på nettstedet ditt, men du viser ikke lekeplassen noe sted. Hvis du bruker en GraphQL-klient i grensesnittet som direkte snakker med GraphQL API-en din, er denne API-en eksponert, selv om den ikke er visuelt eksponert med en GraphQL-lekeplass.

Lekker jeg sensitiv informasjon?

Tillater du en klient å påkalle introspeksjonsspørringen? Lekker du sensitiv informasjon gjennom introspeksjonsspørringen? Planlegger du en ny funksjon i brukergrensesnittet som vil bli offentliggjort om noen uker eller måneder? Er denne funksjonen allerede synlig for konkurrentene dine hvis de ser på skjemaet ditt? Hva om noen skraper skjemaet ditt hver dag for å spore endringer og prøve angrep når du oppdaterer skjemaet ditt?

Skjemaovergangsangrep

Er du klar over skjemaovergangsangrep? En bruker kan få lov til å se sin egen kontosaldo, men hva med vennene hans/hennes? Er det mulig å krysse skjemaet på en måte du ikke forutså hvilke lekkasjer data? Hvordan tester du for denne typen atferd og sikrer at det ikke er mulig for ditt eget skjema?

Bug-premier overalt

Er det en grunn til at selskaper som Shopify deltar i bug bounty-programmer? De ser ut til å være klar over kompleksiteten ved å sikre en GraphQL API. De inviterer sikkerhetseksperter til å hjelpe dem med å gjøre deres offentlig tilgjengelige GraphQL API sikrere. Er du klar over at GraphQL API er like sårbart som Shopifys?

Den sikreste GraphQL-serveren

Hvordan gjøre et system 100% sikkert for alle slags fjernangrep? Hvis du vil være 100 % sikker, bør du vurdere å koble fra nettverkskabelen. Dette kommer imidlertid med noen upraktiske ulemper. Du vil sannsynligvis ikke lagre GraphQL-spørringen din på en USB-dongle, gå til den eksterne datamaskinen og utfør den manuelt, kopier deretter svaret tilbake på dongelen og gå tilbake til din egen datamaskin.

Hva er mellom en frakoblet nettverkskabel og å eksponere GraphQL? Hva med å redusere kompleksiteten til nivået til en REST- eller RPC-basert API mens du beholder fordelene med en spørringsbasert API?

GraphQL som et serversidespråk

Hvis vi primært bruker GraphQL på serveren for å definere JSON-RPC APIer, får vi det beste fra begge verdener. Fleksibiliteten til GraphQL kombinert med sikkerheten og den forutsigbare ytelsen til en RPC-basert API.

GraphQL-spesifikasjonen er designet for dette

GraphQL-spesifikasjonen lar oss definere flere operasjoner (spørringer, mutasjoner, abonnementer) i et enkelt GraphQL-dokument. I tillegg til dette krever valideringsreglene for spesifikasjonen at alle operasjoner i et GraphQL-dokument skal navngis. Det er bare ett unntak som tillater en enkelt anonym spørring. Men i tilfelle antallet operasjoner i et dokument er over 1, er vi allerede tvunget til å navngi operasjonene våre. Et annet viktig krav er at alle operasjonsnavn må være unike. Det vil si at det ikke skal være to operasjoner med samme navn.

Et sett med GraphQL-operasjoner er et JSON-RPC API

Utformingen av GraphQL-spesifikasjonen sammen med valideringsreglene bygger et perfekt grunnlag for det vi prøver å oppnå her.

Hvis vi ønsker å definere en ny JSON-RPC API, er alt vi trenger å gjøre å lage en ny fil som inneholder et sett med GraphQL-operasjoner. Hver operasjon har et unikt navn. Dette navnet blir funksjonsnavnet til JSON-RPC. Operasjonsvariablene blir inngangen til RPC-kallet.

Deretter kan vi "distribuere" alle operasjoner på vår API-backend og forberede RPC-endepunktene. Til slutt, basert på operasjonene og de kjente RPC-endepunktene, er vi i stand til å generere en klient som kjenner til skjemaet så vel som alle RPC-endepunkter.

JSON-RPC-GraphQL sammenlignet med eksponert GraphQL

Fordeler:inndata og utganger er typesikre angrepsoverflaten er redusert du vet at alle operasjonene en klient bruker den genererte klienten er veldig små sammenlignet med en tykk GraphQL-klient, noe som fører til mindre JS-buntstørrelse mindre båndbreddebruk fordi vi ikke sending av operasjoner, men bare foreta RPC-anrop. Spørringsparsing, normalisering og validering skjer på kompileringstidspunktet, ikke under kjøringen, noe som gjør det sikrere og mer ytelsesdyktig. Ingen eksponert GraphQL-endepunkt og derfor ingen eksponert introspeksjon er umulig, siden grafen ikke er eksponert. lenger vet du på forhånd når en endring i skjemaet eller en av operasjonene ville ødelegge en klient og kan redusere denne JSON-RPC gjør en hvilken som helst GraphQL-spørring til en GET-forespørsel og gjør dem derfor lett bufres i transportlaget fordi operasjoner er lagret på backend og aldri eksponert for klienten, kan du sette autorisasjonslogikk inn i Operations

Ulemper:du kan ikke lenger bruke din favoritt GraphQL-klient, du må kjøre en kodegenerator når du oppdaterer skjemaet eller noen av operasjonene du trenger for å kompilere og lagre alle operasjoner på API-backend. Denne tilnærmingen fungerer bare når API-brukeren er tillatelse til å forberede og lagre operasjoner på API-backend

Konklusjon

Å bruke GraphQL som et rammeverk for å bygge JSON-RPC APIer er ikke en løsning på alle problemer. Det er situasjoner der det ikke er gjennomførbart eller rett og slett teknisk umulig. Imidlertid kan mange GraphQL-brukere dra nytte av denne tilnærmingen, siden den øker sikkerheten og ytelsen til marginale kostnader.

Er implementering av denne tilnærmingen din bedrift?

For de fleste av dere vil sannsynligvis svaret på dette spørsmålet være "nei". Hos Wundergraph er målet vårt å gjøre APIer enkle å bruke, sikre og effektive. Vi har allerede implementert tilnærmingen som er skissert ovenfor. Hvis du ikke vil finne opp hjulet på nytt, samarbeider vi mer enn gjerne med deg. Vi fokuserer på rørleggerarbeid, slik at du kan løse problemer med ditt eget forretningsdomene og ikke kaste bort tiden din.

Interessert i å implementere Wundergraph i virksomheten din?

La oss snakke!
https://8bxwlo3ot55.typeform.com/to/bAaZKNd7