Sikkerhet i GraphQL API-er

Begrensning av spørringsdybde er en viktig teknikk for å forhindre overdrevent nestede spørringer. Den angir et maksimalt tillatt nestingsnivå for alle innkommende GraphQL-spørringer.

Hvorfor er dette viktig? Dype spørringer kan føre til:

• Denial of Service (DoS)-angrep ved å tømme serverens ressurser.
• Betydelig redusert ytelse for legitime brukere.
• Unødvendig og kostbar belastning på databasen.

De fleste GraphQL-serverbiblioteker tilbyr enkle måter å konfigurere denne grensen på.

Se for deg en spørring som henter brukere, deretter innleggene deres, så kommentarer til innleggene, deretter forfatterne av kommentarene, og så videre. Dette skaper en dypt nestet struktur:

query DeepQuery {
  users {            # Depth 1
    posts {          # Depth 2
      comments {     # Depth 3
        author {     # Depth 4
          posts {    # Depth 5
            # ... and so on
          }
        }
      }
    }
  }
}

Ved å angi en dybdegrense (for eksempel 5) blokkeres alle spørringer som forsøker å neste data utover dette nivået.

Selv om begrensning av dybden er effektivt, fanger den ikke alltid opp den faktiske kostnaden ved en spørring. En «grunn» spørring kan fortsatt være svært kostbar hvis den ber om et stort antall elementer eller utløser tunge beregninger på hvert nivå.

Komplektivitetsanalyse løser dette ved å tilordne en «kostnad» til hvert felt i skjemaet ditt. Kostnaden kan baseres på faktorer som databaseoperasjoner, API-kall eller krevende beregninger.

Hvert felt i GraphQL-skjemaet ditt kan tildeles en bestemt kompleksitetspoengsum. For eksempel:

• user.id: Lav kostnad, kanskje 1.
• user.posts: Kan ha en grunnkostnad samt en multiplikator basert på antallet innlegg som hentes.
• searchUsers(query: "..."): Kan ha en høyere fast kostnad (for eksempel 10) fordi det gjøres et kall til en ekstern søkemotor.

Den totale kompleksiteten til en spørring beregnes ved å summere disse poengsummene. Hvis den overskrider en forhåndsdefinert terskel, avvises spørringen, og serveren beskyttes.

Akkurat som alle andre backend-API-er krever GraphQL-API-er robust autorisering. Dette sikrer at selv autentiserte brukere bare får tilgang til data og kan utføre handlinger de uttrykkelig har tillatelse til.

I GraphQL implementeres autorisering vanligvis på resolver-nivå. En resolver er en funksjon som er ansvarlig for å hente dataene for et bestemt felt i skjemaet ditt. Dette gir detaljert kontroll.

GraphQLs struktur muliggjør svært detaljert autorisering, ofte helt ned på individuelt feltnivå. Dette kalles autorisering på feltnivå.

En administrator kan for eksempel se alle detaljer (for eksempel e-postadresse og lønn) for et User-objekt, mens en vanlig bruker bare kan se offentlig profilinformasjon (for eksempel brukernavn og biografi) for det samme User-objektet. Resolveren avgjør hvilke data som returneres, basert på rollene eller tillatelsene til brukeren som sender forespørselen.

Her ser du konseptuelt hvordan en resolver for et bestemt felt kan håndheve autorisering:

# Conceptual GraphQL Resolver for 'User.email' field

resolveUserEmail(user, args, context) {
  // 'context' holds info about the authenticated user
  if (context.currentUser.id === user.id || context.currentUser.isAdmin) {
    return user.email;
  } else {
    throw new Error("Unauthorized: You cannot view this email.");
  }
}

Dette kodeeksempelet viser hvordan context-objektet, som inneholder informasjon om brukerens autentisering og rolle, brukes til å avgjøre tilgang.

I dag utforsket vi viktige sikkerhetsaspekter ved GraphQL-API-er. Du lærte om:

• De unike sikkerhetsutfordringene som GraphQLs fleksibilitet introduserer.
• Hvordan begrensning av spørringsdybde bidrar til å forhindre DoS-angrep fra dypt nestede spørringer.
• Hvor viktig komplektivitetsanalyse er for å håndtere ressurskostnaden ved spørringer.
• Implementering av autorisering på resolver-nivå, inkludert tilgangskontroll på feltnivå.

Sikring av GraphQL krever nøye utforming og implementering for å balansere den kraftige fleksibiliteten med robust beskyttelse.