You've inherited Acme Social, a small Django app whose API is served by Strawberry. It works — and it ships with five weaknesses that show up again and again in real GraphQL services. The code is a perfectly ordinary Strawberry/Django setup; the defaults are the problem.

Here's the path a request takes through this lab:

curl / browser
    │  HTTP GET or POST /graphql/ with a GraphQL query or mutation
    ▼
Uvicorn server (port 8000)
    ▼
Django: route request, apply the POST rate limit
    ▼
Strawberry GraphQL view: parse and validate against the schema
    ▼
Execute fields → resolvers → Django ORM → SQLite database
    │
    └── JSON response (data or errors) ──→ curl / browser

GraphQL validation can reject a query before any resolver runs.

Your job: confirm each weakness from the terminal with curl and jq (step 3 also uses the Acme Social browser tab), then fix it in the real project under ~/graphql-lab. After each fix, restart the service so your changes take effect, and the lab will re-check the live endpoint:

sudo systemctl restart graphql-lab.service

It takes a couple of seconds to come back up. If it doesn't (a typo in your edit, say), sudo systemctl status graphql-lab.service shows why.

The project you edit:

• ~/graphql-lab/graphql_lab/schema.py — where the schema is built.
• ~/graphql-lab/graphql_lab/urls.py — where the view is wired up.

Nothing in the code is commented to tell you what to change — that's the point. Everything you need is below.

1. Introspection is wide open

GraphQL introspection lets a client download the entire schema. Handy in development, a gift to an attacker in production.

curl -fsS -G http://127.0.0.1:8000/graphql/ \
  --data-urlencode 'query={__schema{queryType{name} types{name kind fields{name}}}}' \
  | jq .

-G turns --data-urlencode into a URL query string, so this is a plain GET /graphql/?query=.... If introspection is on, the response lists every type and every field.

Disable introspection in the schema, then restart the service.

2. Error messages suggest real field names

Turning off introspection isn't enough. Ask for a field that almost exists and the server helpfully corrects you — rebuilding the schema one guess at a time. GraphQL's security guide explains the risk of revealing field names through error messages; the Clairvoyance tool linked in the Intigriti article automates that kind of schema discovery.

curl -fsS -G http://127.0.0.1:8000/graphql/ \
  --data-urlencode 'query={ usrs { id } }' \
  | jq -r '.errors[].message'

There's no usrs field, so the query fails. Watch the error message for Did you mean ...?

Make the server stop suggesting field names, then restart the service. Keep the Cannot query field validation error readable; the goal is to remove the suggestion, not to replace every validation error with a generic message.

3. Development defaults are still switched on

Two Strawberry defaults help while you build an API, but give away too much once it's live:

• The GraphiQL IDE. Open /graphql/ in a browser and Strawberry serves an interactive query editor with autocomplete and a schema explorer. Anyone who finds the endpoint gets a ready-made tool for probing it.
• Raw resolver errors. When code inside a resolver raises an exception, Strawberry sends the exception's message back to the client unchanged.

Open the Acme Social tab, which shows the app's front page, and follow the /graphql/ link. You land in GraphiQL. The browser gets the IDE because it asks for HTML, so send the same kind of request from the terminal:

curl -s -o /dev/null -w 'HTTP %{http_code}\n' \
  -H 'accept: text/html' http://127.0.0.1:8000/graphql/

HTTP 200 means the IDE page is served.

Now look up a post by ID, once with a malformed ID and once with an ID that doesn't exist:

for id in abc 999; do
  curl -fsS -G http://127.0.0.1:8000/graphql/ \
    --data-urlencode "query={ post(id: \"$id\") { title } }" \
    | jq -r '.errors[].message'
done

Field 'id' expected a number but got 'abc'.
Post matching query does not exist.

Both messages are Django's own wording, raised by the resolver's Post.objects.get(...) call. They tell an attacker the API runs on Django's ORM, and they name a model (Post) and a model field (id) with its type. A client only needs to know that the lookup failed.

Make two changes, then restart the service:

1. Switch off the IDE where the view is wired up, in graphql_lab/urls.py.
2. Mask resolver errors in graphql_lab/schema.py. Mask only errors raised inside resolvers. GraphQL's own validation errors, such as a misspelled field or the limits you'll add in steps 4 and 5, describe the client's query rather than your code, so they should stay readable.

Masking hides the details from clients, not from you: the full exception still goes to the service log, and sudo systemctl status graphql-lab.service shows its last lines.

Once both changes are live, the IDE request returns HTTP 404 (the tab's /graphql/ link shows Not Found) and both lookups print Unexpected error. The check also confirms that a misspelled field still gets its validation message and that a lookup with a real ID still works.

4. Field aliases bypass the rate limiter

The endpoint has a per-request rate limiter (60 POSTs a minute per client address), so a brute-force of the verifyOtp mutation should be slow. But GraphQL lets one request alias the same field many times — and the limiter counts that as a single request.

First build one mutation that packs 60 OTP guesses, each under its own alias (a0, a1, ...):

Q="mutation{ $(for i in $(seq 0 59); do printf 'a%d: verifyOtp(code:"%04d"){ ok } ' "$i" "$i"; done)}"
echo "$Q"

Then send it as a single POST:

curl -s -X POST http://127.0.0.1:8000/graphql/ \
  -H 'content-type: application/json' \
  --data "$(jq -nc --arg q "$Q" '{query: $q}')" \
  | jq '{attempts: (.data | length), errors: (.errors | length)}'

jq -n --arg wraps the query in a JSON request body and handles the quoting. attempts: 60 means all 60 guesses ran inside one rate-limited request. GraphQL's security guide recommends limiting aliases within an operation.

Strawberry provides a built-in alias limiter, but in this exercise you'll write a small graphql-core validation rule that counts aliased fields and rejects a request with too many. Define the rule in graphql_lab/schema.py, register it on the schema, then restart the service.

5. A single deep query can exhaust the server

Post.author and User.posts reference each other, so a query can nest as deep as a client likes. With no depth limit, one request can force an enormous amount of work. GraphQL's security guide recommends limiting operation depth.

curl -s -G http://127.0.0.1:8000/graphql/ \
  --data-urlencode 'query={ me{ posts{ author{ posts{ author{ posts{ id }}}}}} }' \
  | jq '{data_present: (.data != null), errors: (.errors | length)}'

data_present: true with no errors means the server resolved the whole chain (vulnerable). A depth-limit error means it refused (fixed).

Choose a cap that still allows the app's normal pages. The calculation below shows how to count their depth and compare it with the probe.

Add the limit to the schema, then restart the service. Then check both sides: the probe above should now get a depth-limit error, and the post page should still return data:

curl -s -G http://127.0.0.1:8000/graphql/ \
  --data-urlencode 'query={ post(id: "1") { title author { username posts { title } } } }' \
  | jq .

The check sends both queries.

Done

You've taken a stock GraphQL service and closed five weaknesses: introspection, field suggestions, development defaults left on (the GraphiQL IDE and raw resolver errors), alias-based rate-limit bypass, and unbounded query depth. Same service, hardened defaults.

Editorial solution: Harden the GraphQL API

The five checks target separate weaknesses. You can apply the changes one at a time and watch each task complete, or combine them as shown below. Start by inspecting ~/graphql-lab/graphql_lab/schema.py and ~/graphql-lab/graphql_lab/urls.py. After editing either file, restart the service with sudo systemctl restart graphql-lab.service.

1. Stop schema introspection

The __schema query works because Strawberry enables introspection by default. Add DisableIntrospection() to the schema extensions. This blocks that query; it does not change normal application queries or GraphQL's validation messages.

2. Stop field-name suggestions

The misspelled usrs query exposes the real users field through a validation error. Set StrawberryConfig(disable_field_suggestions=True) on the schema. Afterward, the error should still say Cannot query field 'usrs', without a Did you mean suggestion. Keeping the validation error readable matters: masking every error only hides the suggestion and makes the API harder to use.

3. Turn off development responses

Pass graphql_ide=None to GraphQLView.as_view(...) in urls.py to stop serving GraphiQL. Separately, add MaskErrors to the schema extensions with a predicate that masks only errors raised inside resolvers. These have a non-null original_error; GraphQL validation errors do not. A plain MaskErrors() is too broad: it also hides useful validation errors from clients.

4. Bound aliases per operation

The rate limiter counts HTTP POSTs, while GraphQL aliases let one POST carry many verifyOtp calls. A GraphQL validation rule can reject an operation before any of its resolvers run. The example below allows up to 15 aliased fields, including ordinary uses of aliases, and rejects the lab's 60-alias probe. It leaves a normal single mutation usable.

5. Limit query depth

User.posts and Post.author form a cycle, so a client can make a very deep query. Strawberry's QueryDepthLimiter counts the longest field path but excludes its leaf field. The post-page query needs depth 3; the attack probe has depth 6. max_depth=3 preserves the post page and stops the probe. Values 4 and 5 also pass the check if the application needs more headroom.

Combined example

Replace ~/graphql-lab/graphql_lab/schema.py with:

import strawberry
from graphql import GraphQLError
from graphql.language import BREAK
from graphql.validation import ValidationRule
from strawberry.extensions import (
    AddValidationRules,
    DisableIntrospection,
    MaskErrors,
    QueryDepthLimiter,
)
from strawberry.schema.config import StrawberryConfig

from blog.schema import Mutation, Query

MAX_ALIASES = 15


class MaxAliasCountRule(ValidationRule):
    def __init__(self, context):
        super().__init__(context)
        self.alias_count = 0

    def enter_field(self, node, *_args):
        if node.alias is None:
            return
        self.alias_count += 1
        if self.alias_count > MAX_ALIASES:
            self.report_error(
                GraphQLError(
                    f"Too many aliases: {self.alias_count} exceeds the "
                    f"limit of {MAX_ALIASES}.",
                    node,
                )
            )
            return BREAK


schema = strawberry.Schema(
    query=Query,
    mutation=Mutation,
    config=StrawberryConfig(disable_field_suggestions=True),
    extensions=[
        DisableIntrospection(),
        MaskErrors(
            should_mask_error=lambda error: error.original_error is not None
        ),
        AddValidationRules([MaxAliasCountRule]),
        QueryDepthLimiter(max_depth=3),
    ],
)

In ~/graphql-lab/graphql_lab/urls.py, change the view creation to:

graphql_view = ratelimit(key="ip", rate="60/m", method="POST", block=True)(
    csrf_exempt(GraphQLView.as_view(schema=schema, graphql_ide=None))
)

Leave the other imports, route definitions, and rate limiter in that file as they are. Restart the service and repeat the probes in the challenge. You should see introspection rejected, a readable usrs error without a suggestion, no GraphiQL page, masked resolver exceptions, the 60-alias request rejected, and the depth-6 query rejected. The normal post-page query and a single OTP mutation should still work.