Penetration testing cost is what a provider charges to test a system for security flaws, and it is usually priced per test, per year or per asset. On 9 November 2026 we read the pricing pages of 66 providers. 21 of them publish at least one price, which gives 68 price rows. For prices in US dollars sold per test, the median is $5,000 across 21 rows from 9 providers. The range is $1,000 to $27,120. 14 of those 21 rows are starting prices.

The data comes from the PentestCompare pricing index, which our lab publishes. Every row below links to the provider's own pricing page.

On this page: Prices by billing unit · Every per-test price · By delivery model · How we counted · How to read the numbers · Our own price · Data

Pentest prices by billing unit

Providers bill in different units, so we never mix them. A median appears only where 3 or more providers share a group. In the other groups the table shows the lowest and highest price only. Each group is split by currency.

Published prices by billing unit and currency (checked 9 November 2026)

Only the per-test group in US dollars has enough providers for a median in a project-sized unit. The per-month median comes from 6 monthly plans from 3 providers. Those are subscription tiers, so we do not read it as the price of one test.

The dataset has no field for test type, such as web application, API, cloud or network. It cannot give a median for each test type. Where a provider names a scope in a price row, the table of per-test prices below shows it. For example, Secure Ideas lists a smallest-scope External Penetration Test at $8,160, an API Penetration Test at $10,880 and a Web Application Test at $13,600.

Every per-test price in US dollars

Each row is one published price. "Starting price" is Yes when the amount or unit says "from", "starts at" or "starting", or when the provider calls it the smallest scope.

All 21 per-test prices in US dollars, lowest first

One euro row sits outside this table. Hadrian lists "From EUR 1,250" per test, excluding VAT.

The widest spread is inside single providers. Synack's three starting prices run from $5,085 to $27,120. CYBRI's four run from $2,500 to $20,000. A provider's scope note decides whether two numbers describe similar work.

The 7 exact prices, without a starting label, have a median of $3,500 across 5 providers: Aikido, Cobalt, Intruder, Prescient Security and Stingrai. The Cobalt $3,500 row is a limited-time offer. Its page says the test must start and finish before 31 December 2026.

Per-test prices by delivery model

The delivery model is the dataset's label for each provider: human-led, hybrid or automated.

Per-test prices in US dollars, by delivery model

Human-led and automated providers each have 2 providers with per-test rows, so we compute no median for them. The sample is too small to call one model cheaper than another.

How we counted

• Predicate. A price counts when the provider shows an amount on its own public pricing page. We copied the amount, unit, scope note and page URL. We used no search snippets and no estimates.

• Date. We checked every row on 9 November 2026. We have not rechecked them since this page was written. Prices change often.

• Count. 66 providers in the set. 21 publish at least one price. 45 publish none. The 21 providers give 68 price rows. 50 rows fit a unit class and 18 do not, for example free tiers and packs. We list the 18 rows and the reason for each in the data file.

• Number used. For a range such as "640 EUR to 890 EUR" we use the first number.

• Provider set. The 66 providers are a researched set, not every pentest provider. We did not choose by quality or size. We tested no service and read no customer quote.

How to read the numbers

These are list prices. The data holds nothing on what buyers paid. A quote after scoping can be higher or lower.

The set under-counts providers that quote after scoping. Of the 66 providers, 37 use a custom quote as their pricing model. The prices above come from the 21 that publish.

Our own price

We are not in these medians. Our lab publishes the dataset and competes with the providers in it. We publish no price list. Each test gets a written quote after a short scoping call. The pricing page lists what sets a quote. For the service itself, see penetration testing.

Data files

• prices.csv: 68 rows, each with a source URL and check date.

• pricing-index-2026.csv: the same rows with unit class, delivery model, and the reason a row is not comparable.

• README.txt and SHA256SUMS.

• PentestCompare pricing index and the full dataset on GitHub (MIT licence).

Originally published at https://excessionlabs.ai/blog/penetration-testing-cost/ . The test code and recorded output are there.

PKCE (Proof Key for Code Exchange, RFC 7636) makes a stolen authorization code useless on its own. In our local toy server without PKCE, a party holding only an intercepted code received an access token in all four interception flows. With an S256 code challenge enforced, the three interception attempts that reached the token endpoint got 400 invalid_grant, a client with no challenge was refused at the authorization endpoint, and the legitimate client still received its token.

This is a scripted Python and curl experiment with downloadable source and responses. No AI agent or model ran the test.

On this page: PKCE flow · Scope · Reproduce the run · Observed results · Verify the finding · Fix and retest · Evidence · Limits

How the PKCE flow stops authorization code interception

In the OAuth authorization code grant, the authorization server sends a short-lived code to the client's redirect URI, and the client trades it for an access token. A public client such as a mobile app cannot keep a secret, so anyone who holds the code and the public client_id can make the same trade. RFC 7636 calls this the authorization code interception attack. Its example is a malicious app that registers the same custom URI scheme as the real app and receives the redirect.

The PKCE flow adds one secret that never travels in the redirect. For each authorization request the client creates a code verifier: a random string of 43 to 128 unreserved characters, and RFC 7636 recommends 32 random octets base64url-encoded, which gives 43 characters. It sends a code challenge in the authorization request. With the S256 method, the code challenge is the base64url-encoded SHA-256 hash of the code verifier. The server stores the challenge with the code. At the token endpoint the client sends the code verifier, the server hashes it and compares, and a mismatch must return invalid_grant.

This post covers PKCE only. Other OAuth weaknesses are out of scope.

Scope of the fixture

• A toy authorization server with two endpoints, GET /authorize and POST /token, bound to IPv4 loopback 127.0.0.1 on a free port the runner picks.

• One synthetic public client, demo-public-app, with the registered redirect URI demoapp://callback. Nothing listens there. curl never follows the redirect, so the runner reads the Location header, which is what a malicious app registered for that scheme would receive.

• One user who is already signed in and consents. There is no login page.

• The interceptor holds the code, the client_id and the redirect URI. It never sees the code verifier. In one flow it also saw the authorization request, so it knows the code challenge.

Vulnerable mode ignores code_challenge and code_verifier. Fixed mode enforces them. Each flow uses its own authorization code, because the server consumes a code on its first use. Tokens, codes and verifiers are one-time demo strings. To test a real system, agree hosts, accounts and stopping conditions with its owner first. The Acceptable Use Policy describes authorized use, and this article gives no permission to test another system. The fixture matches the redirect URI as one exact string and does not cover redirect handling in general, which open redirect covers.

Run the downloadable fixture

Download fixture.py and verify.py into one directory. You need curl and Python 3; the code uses only the standard library, and we ran it on Python 3.15.2 only. Read the source, then run:

python3 verify.py --output rerun

The output directory must be new. The runner starts each mode in turn, runs six flows per mode with real curl requests, saves every response and stops the servers. Each request bypasses proxies with --noproxy '*', has a one-second connect timeout and a three-second total timeout, and follows no redirects.

Our recorded command was python3 verify.py --output recorded-run, run on 11 November 2026 at about 09:58 UTC with fixture version 1.0.0, Python 3.15.2 and curl 8.7.1 on macOS ARM64. It printed {"checks": 12, "passed": true, "failures": []}. That line means each flow matched what we expected from that mode, including the intended failures in vulnerable mode. It also recomputes the RFC 7636 Appendix B example, where the verifier dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk must produce the challenge E9Melhoa2OwvFrEMTJguCHaoeK1t8URWbuGJSstw-cM. That value matched. Versions, UTC times, commands and source SHA-256 values are in results.json.

Compare vulnerable and fixed mode, with controls

The legitimate client flow is the positive control: it must keep working after the fix. The three interceptor flows send a missing, a guessed and a replayed verifier. The last two rows start from clients that break the fixed server's rules: no challenge at all, and the plain method.

Recorded outcomes of 12 local flows

In vulnerable mode the interceptor got a token in all four of its flows (rows 2 to 5 of the table). The server accepted an S256 challenge in rows 2 to 4 and never checked it. In fixed mode no interceptor received a token. Rows 5 and 6 never reached the token endpoint because the authorization endpoint refused the request.

The refusals follow RFC 7636. Section 4.4.1 says a server that requires PKCE must answer a missing code_challenge with the invalid_request error, and a server that does not support the requested transformation must do the same. The fixed server supports S256 only. Section 4.3 makes the method default to plain when it is absent, and section 4.2 allows plain only for clients that cannot use S256 and know the server supports it. Refusing plain is therefore a server choice. Section 7.2 gives the reason: with plain, the challenge equals the verifier, so an attacker who observes the authorization request can learn the verifier. We did not run that attack.

The replayed-challenge row models the more capable attacker from section 1 of the RFC, who can also observe authorization requests. Replaying the observed challenge failed because the server hashes whatever it receives, so the result no longer equals the stored value. That shows one shortcut fails and nothing more about SHA-256.

Verify a missing-PKCE finding before you report it

A missing or unenforced code challenge is a finding only when an interceptor's request succeeds. Check both halves against a test account you control. First, send an authorization request with no code_challenge and see whether you get a code or an error. Second, redeem a code from a flow that did include a challenge, without the code verifier, and see whether you get a token. A server that rejects the first request but accepts the second enforces PKCE on one path only, and the second request is the one that matters for interception. Repeat for each registered public client, since enforcement can differ per client.

The recorded vulnerable-mode request for the interceptor with no verifier used port 50601. It carries the code the client's redirect returned and no code_verifier. This is the executed command, reformatted across lines:

curl --noproxy '*' --silent --show-error --include \
  --http1.1 --connect-timeout 1 --max-time 3 --request POST \
  --data 'grant_type=authorization_code&code=Awb_hZZmRxtiNaCBTgiQqw&client_id=demo-public-app&redirect_uri=demoapp%3A%2F%2Fcallback' \
  http://127.0.0.1:50601/token

The recorded response holds the token; headers are omitted:

HTTP/1.0 200 OK

{"access_token": "demo-access-c0c5d7751b00", "token_type": "Bearer"}

The matching authorization request had carried an S256 code_challenge, as the authorization response and commands.sh show. A report should name the client, the endpoints, what the authorization request contained, what the interceptor sent and the response it received. This run proves a token was issued without the verifier in a fixture. It gives no severity for a real system, and it does not show that anyone can read a real user's redirect. That depends on the platform.

Require an S256 code challenge and retest

The same fixture source holds both modes. In fixed mode the authorization endpoint refuses a request without a challenge or with any method other than S256:

if self.server.mode == "fixed":
    if not challenge:
        return self.redirect_error("invalid_request", "code challenge required", q)
    if method != "S256":
        return self.redirect_error("invalid_request", "transform algorithm not supported", q)

The token endpoint recomputes the challenge from the verifier it receives and compares it with the one stored for that code:

verifier = form.get("code_verifier", "")
ok = bool(verifier) and verifier.isascii() and hmac.compare_digest(s256(verifier), record["challenge"])
if not ok:
    return self.reply(400, {"error": "invalid_grant"})

The helper is s256(verifier), which returns the base64url encoding, without padding, of the SHA-256 hash of the ASCII verifier. The fixture returns invalid_grant for a missing verifier as well as a wrong one. RFC 7636 section 4.6 names invalid_grant for a mismatch and does not name the error for an absent verifier, so another server may answer differently.

The runner restarted the server in fixed mode on port 50617 and repeated the six flows. The interceptor with no verifier got 400 with {"error": "invalid_grant"}. The legitimate client's token request returned 200 with a token. The client with no challenge was sent to demoapp://callback with error=invalid_request and the description code challenge required, as recorded here. Refusing a request with no challenge breaks old clients. Update them to send a challenge before you enforce it on a live server.

Inspect the evidence bundle

• Machine-readable results: all 12 flows, expected and observed outcomes, response filenames and hashes.

• Exact recorded curl commands: the ports belong to the finished run. Use the runner to start fresh servers.

• SHA-256 manifest: an integrity check against your downloads, not independent attestation.

• Fixture notes, server source and verification source.

The fixture is also on GitHub: web-security-fixtures. The bundle holds the raw response text, and all values in it are synthetic.

What this experiment does not cover

Twelve flows against a toy server show one boundary: with PKCE enforced, a code alone cannot be redeemed here. We did not test a real operating system hijacking a custom URI scheme, TLS, code expiry, confidential clients, refresh tokens, or redirect URI matching beyond one exact string. The fixture does not check the length or character set of the challenge or verifier against the 43 to 128 character rule in RFC 7636. It consumes a code on any attempt, so we never raced an attacker and the real client for one code. It also does not test the downgrade attack in section 7.2, where a man in the middle causes an S256 error to push the client to plain. The RFC says clients must not fall back to plain after S256 fails.

The authorization server's token rules come from RFC 6749, which says in section 10.5 that authorization codes must be short lived and single use. PKCE adds to those rules and does not replace them. For checks on the APIs behind the token, see API authorization testing.

Excession Labs runs this kind of check in its security assessments.

Originally published at https://excessionlabs.ai/blog/pkce/ . The test code and recorded output are there.

Row level security (RLS) is a PostgreSQL feature that limits which table rows each role can read or write, based on policies. In a throwaway PostgreSQL 16.15 cluster, we reproduced three ways it fails without raising an error: a table with no RLS enabled, an application that connects as the table owner, and write policies that never check the tenant. Each let one tenant read or change another tenant's invoices. The fixed configuration denied every attempt and left legitimate access working.

This is a scripted Python and psql experiment with downloadable source and recorded output. No AI agent or model ran the test.

On this page: Definition · Scope · Reproduce · Results · USING and WITH CHECK · Verify · Fix and retest · Limits

What Postgres row level security does

Row level security (RLS) lets PostgreSQL filter rows for each query. A policy attaches to a table and holds up to two expressions. USING decides which existing rows a role can see or target. WITH CHECK decides which new or changed rows a role may store. The PostgreSQL manual describes the feature in Row Security Policies and gives the syntax in CREATE POLICY.

Supabase RLS uses this same PostgreSQL feature, but we did not test Supabase. Every command here runs on plain PostgreSQL, and the three mistakes apply wherever the same policies are used.

Scope of the fixture

• Target: a cluster that initdb creates in a temporary directory, started on a unix socket inside that directory with listen_addresses empty. There is no TCP listener. The runner deletes the cluster at the end.

• Roles: app_owner owns the table and is not a superuser. app_user is the role the application should use. The postgres superuser only reads state back.

• Tenant context: after connecting, the application runs SET app.tenant_id = 'acme'. Policies read the value with current_setting('app.tenant_id', true).

• Data: one invoices table with four synthetic rows, two for tenant acme and two for tenant globex.

The fixture is intentionally insecure in its vulnerable configurations and touches nothing outside its temporary directory. The Excession Labs Acceptable Use Policy describes authorized use. This article gives no permission to test another system. For related reading on the same boundary, see tenant isolation and broken access control.

Run the downloadable fixture

Download fixture.py and verify.py into one directory. You need Python 3.9 or later and a PostgreSQL install that provides initdb, postgres, pg_isready and psql. We ran PostgreSQL 16.15 only. Run:

python3 verify.py --output rerun

The output directory must be new. For each configuration the runner creates a fresh database, loads the table, applies the policies, then opens a separate psql session per test. It saves each session's full output and stops and deletes the cluster. No network target, login or paid API is involved.

Our recorded command was python3 verify.py --output recorded-run, run on 10 November 2026 with Python 3.15.2 on macOS arm64. It printed {"checks": 30, "passed": true, "failures": []}. That means every case matched its expected outcome, including the vulnerable ones, and that results.json records "cluster_deleted": true. The cluster used port 53847 on a unix socket that no longer exists.

Postgres row level security: observed results

Each mistake has a vulnerable configuration and a fixed one. The positive controls confirm that legitimate access survives the fix. The negative controls confirm that denial happens where the policy says it should.

Recorded psql results in a fresh database per configuration. Tenant is acme unless noted.

The superuser row is not a failure. PostgreSQL documents that superusers and roles with the BYPASSRLS attribute always bypass row security, and that FORCE ROW LEVEL SECURITY does not change that.

A policy with only USING was not the flaw

Before the run we expected that a policy with USING and no WITH CHECK would let a tenant write into another tenant. It did not. A single FOR ALL policy with only USING denied both the cross-tenant INSERT and the unconditional UPDATE in the control database. The CREATE POLICY page explains why: if only a USING clause is specified, that clause is used for both the USING and WITH CHECK cases.

The flaw appeared when someone wrote an explicit WITH CHECK that left the tenant out. An explicit check replaces the default, so WITH CHECK (amount >= 0) validated the amount and allowed any tenant value. The UPDATE with a WHERE clause was denied even in the vulnerable configuration. The manual says that when an UPDATE reads columns, for example in its WHERE clause, the SELECT policy is also checked against the existing and the new row. The new globex row failed the SELECT policy. An UPDATE that reads no column skips that check, so the unconditional one above moved all three visible acme rows.

Verify the finding before you report it

Capture the session, the role and the table state. Three recorded excerpts follow.

Mistake 1. Tenant acme runs a query that forgot its WHERE clause on a table without RLS (full output):

SET app.tenant_id = 'acme';
SELECT id, tenant_id, amount FROM invoices ORDER BY id;
 id | tenant_id | amount 
----+-----------+--------
  1 | acme      |    100
  2 | acme      |    250
  3 | globex    |    400
  4 | globex    |     75
(4 rows)

Mistake 2. RLS is enabled and the policy exists, yet the owner role gets the same four rows (full output). The flags in pg_class explain it: relrowsecurity is t and relforcerowsecurity is f (output). Also check pg_roles for rolsuper and rolbypassrls on the role your application uses. We did not run that query in the fixture.

Mistake 3. After the two vulnerable writes, a superuser reads every row (full output). Row 5 was inserted into globex by an acme session, and the unconditional UPDATE moved rows 1, 2 and 6 to globex:

id | tenant_id | amount 
----+-----------+--------
  1 | globex    |    100
  2 | globex    |    300
  3 | globex    |    400
  4 | globex    |     75
  5 | globex    |    999
  6 | globex    |     10
(6 rows)

A useful report names the connecting role, the table, the policy definitions, the exact statement and the rows that changed. Read the data back as a second identity. A write that reports success is not proof until you see the row.

Fix the RLS policy and retest

Mistake 1 is fixed by enabling RLS and adding a policy. Mistake 2 needs one more statement from fixture.py:

ALTER TABLE invoices FORCE ROW LEVEL SECURITY;

With that line, the owner role returned 2 rows instead of 4. The superuser still returned 4. For mistake 3, the fixed write policies check the tenant as well as the amount:

CREATE POLICY tenant_insert ON invoices FOR INSERT
  WITH CHECK (tenant_id = current_setting('app.tenant_id', true) AND amount >= 0);
CREATE POLICY tenant_update ON invoices FOR UPDATE
  USING (tenant_id = current_setting('app.tenant_id', true))
  WITH CHECK (tenant_id = current_setting('app.tenant_id', true) AND amount >= 0);

We retested every case against the fixed databases. The cross-tenant INSERT and both cross-tenant UPDATEs returned ERROR: new row violates row-level security policy for table "invoices". Acme could still insert its own row and change its own amount, and the negative amount was still refused. The final table held five rows with rows 1, 2 and 6 still under acme (output).

Our recommendation, which the fixture does not test, is to connect the application as a role that does not own the tables and has no BYPASSRLS. Keep the owner role for migrations. FORCE then acts as a second layer if the wrong role is ever used.

Inspect the evidence bundle

• Machine-readable results: all 30 cases, roles, SQL, expected and observed outcomes, versions and hashes.

• Recorded psql commands: the socket directory and port belong to the finished run. Use verify.py for a fresh cluster.

• SHA-256 manifest: an integrity check, not independent attestation.

• Fixture instructions and limits, fixture source and verification source.

All data is synthetic. No production credentials, customer records or external services were involved.

What this experiment does not cover

This is one table in one PostgreSQL version, 16.15, with trust authentication on a unix socket. We did not test DELETE, restrictive policies, several permissive policies on one table, views, security-definer functions, ON CONFLICT upserts, connection pools that reuse a session with a stale app.tenant_id, the BYPASSRLS attribute, or Supabase. The fixed result says nothing about an unrelated schema.

In a real engagement, list each table that holds tenant data, record the role the application connects as, and test reads and writes from two tenants. Retest the same cases after every policy change. Keep failed and inconclusive runs with the successful ones. The same two-identity method applies to HTTP APIs, as shown in API authorization testing.

Excession Labs runs this kind of test in its security assessments, using a second tenant account to prove each cross-tenant effect. See how a finding like this looks in a sample report.

Originally published at https://excessionlabs.ai/blog/row-level-security/ . The test code and recorded output are there.

GraphQL introspection lets a client ask the server for its whole schema. Turning it off hides the field list, but a client that knows or guesses a field name can still call it. We sent 24 curl requests to a local GraphQL server with an unlisted admin field. With introspection on, a normal user listed the field and read another user's record. With introspection off the field still answered by name, and the error messages still suggested its name. An authorization check in the resolver blocked the read.

This is a scripted Python and curl experiment with downloadable source and responses. No AI agent or model ran the test.

On this page: Scope · Reproduce the run · Observed results · Verify the finding · Fix and retest · Evidence · Limits

What GraphQL introspection exposes, and the scope of this fixture

GraphQL introspection lets a client query a service for its own schema. The GraphQL specification says a service supports introspection over its schema and that the schema is queried using GraphQL itself. Tools use this to build documentation and autocomplete. An attacker uses the same query to list every field, including fields the public client never calls.

Our policy is small. Alice, Bob and an admin are users with synthetic records. Only the admin may call adminUserRecord(id), which returns any user's email and the last four digits of a made-up national ID. Ordinary users may call me. The public client uses only me, so nobody documented the admin field.

• Target: four short-lived GraphQL servers bound to 127.0.0.1 on OS-assigned ports, built on graphql-core 3.2.14.

• Requests: 24 POST requests to /graphql, six per server.

• Identities: public demo bearer values for alice, bob and admin. They are fixed test strings with no value outside this fixture.

• Data: three synthetic records in memory, with example.invalid addresses.

The vulnerable configuration is insecure on purpose, so the server binds only to loopback. Test a real system only with the owner's written permission; the Acceptable Use Policy describes authorized use. This article gives no permission to test any other system.

Run the downloadable fixture

Download fixture.py and verify.py into one directory. You need Python 3.9 or later and curl. The fixture also needs graphql-core, so the runner builds a temporary virtual environment, installs the pinned version 3.2.14 from PyPI into it and deletes it afterwards. Nothing is installed globally. Read the source, then run:

python3 verify.py --output rerun

The output directory must be new. Each curl request bypasses proxies, has a one-second connection timeout and a three-second total timeout, and does not follow redirects. The four server configurations are:

• A, vulnerable: introspection on, no check in the resolver.

• B, introspection off: the schema query is rejected, no check in the resolver.

• C, authorization check: introspection on, the resolver requires the admin role.

• D, check and introspection off: both changes together.

Our recorded command was python3 verify.py --output recorded-run. It exited with {"checks": 24, "passed": true, "failures": []}. That means every response matched what we expected to see, including the intentionally vulnerable ones. The run started at 22:46 UTC on 10 November 2026 with fixture version 1.0.0, Python 3.15.2, graphql-core 3.2.14 and curl 8.7.1 on macOS ARM64. Ports, timestamps and hashes are in results.json. A rerun uses different ports and response dates.

Observed results: introspection off, field still callable

Every request in the table used the stated identity. Alice is an ordinary user, so the policy expects her call to adminUserRecord for Bob to fail. The authenticated cases all returned HTTP 200 because the fixture reports GraphQL errors in the body, as many servers do. The anonymous request returned 401.

Observed results from 24 local requests (HTTP status, then what the body contained)

Row three is the finding. Configuration A leaks Bob's record. Configuration B, with introspection disabled, leaks the same record to anyone who already knows or guesses the name. Rows four and five are the positive controls: legitimate use still works after the fix, and the admin still reaches the field. The 401 row shows that authentication is present in all four configurations, so the gap is the authorization decision that comes after login.

The misspelling row is important if you rely on the introspection setting. In graphql-core 3.2.14, query validation adds a "Did you mean" hint to the unknown-field error, and the hint appeared in all four configurations. The OWASP GraphQL Cheat Sheet describes the same behavior and notes that attackers can still guess fields when introspection is off. Other servers and versions may differ; we tested only this one.

Verify the finding before you report it

In the recorded configuration B run, Alice's request used port 53294. This is the executed command with the body shown on its own line:

curl --noproxy '*' --silent --show-error --include \
  --http1.1 --connect-timeout 1 --max-time 3 --request POST \
  --header 'Content-Type: application/json' \
  --header 'Authorization: Bearer demo-alice-token' \
  --data '{"query": "{ adminUserRecord(id: \"bob\") { id email ssn_last4 } }"}' \
  http://127.0.0.1:53294/graphql

The recorded response body is:

{"data": {"adminUserRecord": {"id": "bob", "email": "bob@example.invalid", "ssn_last4": "2222"}}}

This is a finding because the token belongs to Alice, whose role is user, and the response contains fields from Bob's record. A 200 status alone proves nothing for GraphQL, because errors travel inside a 200 response. Read the data member and compare it with a control, here the admin call that returns the same record and the me call that returns Alice's own email.

Record the query text, the identity, the owner of the returned record, the policy that should have denied it and the response fields. Here the impact is disclosure of one synthetic record. We did not rate severity for any real system.

Fix with resolver authorization, then retest

Disabling introspection is one line in graphql-core. It adds a validation rule that rejects schema queries:

rules = list(specified_rules)
if not self.server.introspection:
    rules.append(NoSchemaIntrospectionCustomRule)

Configuration B used that rule. It removed the schema listing and left the field callable. The graphql.org introspection guide describes disabling introspection in production as common attack-surface reduction and describes it as one part of a broader strategy that also includes authentication and authorization. The OWASP cheat sheet recommends disabling introspection and also says to validate in every resolver that the requester may view the data. The check that fixed this fixture is in the resolver:

def resolve_admin_user_record(root, info, id):
    if info.context["authz"] and ROLES[info.context["identity"]] != "admin":
        raise GraphQLError("forbidden", extensions={"code": "FORBIDDEN"})
    return USERS.get(id)

In configuration C the runner repeated the same six requests with this check on and introspection still enabled. Alice's call for Bob returned forbidden with data null. The admin and me controls still returned data, and the anonymous request still returned 401. Configuration D, with both changes, gave the same call results. In C the schema listing still named the field, and the call was still denied, so the resolver check alone protected it.

The check suits this toy policy, which has one role. A real service also needs per-object ownership, tenant membership and rules for nested fields and mutations. In the fixed configurations the unknown-field hint still names adminUserRecord. Once the resolver denies the call, that leak has low impact, but it still tells an attacker the field exists. The cheat sheet lists suggestions for mistyped fields among its introspection items; we did not test a change for that.

Inspect the evidence bundle

• Machine-readable results: all 24 cases with identities, queries, expected and observed outcomes, response filenames and hashes.

• Exact recorded curl commands: the ports refer to the finished run. Use the runner to create fresh servers.

• SHA-256 manifest: compare downloaded files with ours. This is an integrity check, not independent attestation.

• Instructions and limitations, server source and verification source.

All bearer values and records are synthetic. The bundle includes full response text with dates and server headers. No production credentials or customer data were involved.

What this experiment does not cover

We tested one toy schema with one query field per role on one library version. We did not test mutations, subscriptions, nested types, batching, aliases, query depth, GraphiQL or other schema-exploration tools, other GraphQL servers, persisted queries, or real error-masking settings. graphql-core disables introspection with a validation rule. Other servers use different switches. Check yours by running the same six requests.

For a real test, list the fields in the schema, mark which roles may call each one, and send each field with a low-privilege account and a second account's object IDs. Test again with introspection off, because, as the OWASP sheet notes, attackers can still guess field names by brute force. Related reading: API authorization testing, broken access control and the OWASP API Top 10.

Excession Labs runs this kind of authorization testing in its security assessments, including checks of GraphQL fields with and without introspection. See how a finding like this looks in a sample report.

Originally published at https://excessionlabs.ai/blog/graphql-introspection/ . The test code and recorded output are there.

Server-side request forgery (SSRF) is a flaw where a server fetches a URL chosen by the caller, so the caller can reach hosts that only the server can reach. We built a small URL-preview endpoint, pointed it at a second loopback server that stands in for an internal metadata service, and read a synthetic secret back in real HTTP responses. A denylist of host strings was bypassed by a decimal IP encoding and by a redirect. A resolved-address allowlist with redirects turned off stopped both, and the legitimate preview still worked.

This is a scripted Python and curl experiment with downloadable source and responses. No AI agent or model ran the test.

On this page: Scope · Reproduce the run · Observed results · Naive fix and bypasses · Fix and retest · Limits

Define the SSRF scope and test fixture

An SSRF vulnerability exists when a server builds an outbound request from caller input and sends it from its own network position. A URL-preview feature is a common example. The caller supplies a URL, the server fetches it to show a title or thumbnail, and nothing stops the URL from pointing at an internal host.

This fixture has three roles, each a small standard-library HTTP server bound to IPv4 loopback, 127.0.0.1:

• target stands in for the public site the preview feature is meant to fetch. It serves /article, an ordinary page, and /redirect, which answers with a 302.

• metadata stands in for an internal metadata service. It serves one path, /latest/meta-data/secret, and holds one synthetic credential string.

• preview is the endpoint under test: GET /preview?url=<url>. It fetches the given URL and reports what it found. A --mode flag selects one of three defenses: vulnerable (none), naive (block one hostname string), or strict (resolve, check the resolved address against an allowlist, do not follow redirects).

This demonstrates the class CWE describes as CWE-918, Server-Side Request Forgery (SSRF): a web server receives a URL from an upstream component and retrieves it without adequately verifying that the request goes to the intended destination.

• Allowed requests: four GET requests to the preview endpoint, repeated across three defense modes, twelve in total.

• Addresses: the symbolic name target.test, the literal address 127.0.0.1, and the decimal IP encoding 2130706433 (the same loopback address written as one 32-bit integer). All three resolve to 127.0.0.1; the fixture never leaves loopback.

• Data: one synthetic metadata secret and one synthetic article page, both held in memory. There are no customer records, external services, or database writes.

The fixture resolves target.test from a fixed local table instead of real DNS, so the run is offline and repeatable. The literal and decimal forms go through the normal socket layer, which turns both into 127.0.0.1. The fixture always listens on loopback. For a staging engagement, agree the hosts, accounts and stopping conditions with the system owner first. The Excession Labs Acceptable Use Policy describes authorized use. This article gives no permission to test another system.

Run the downloadable fixture

Download fixture.py and verify.py into the same directory. You need Python 3.9 or later and curl; the Python code uses only the standard library. Inspect the source, then run:

python3 verify.py --output rerun

The output directory must be new. The runner starts the target and metadata servers once, then starts the preview server three times, once per mode. It sends four curl requests to each mode, saves every response and stops every server before it exits. Each curl request bypasses proxies with --noproxy '*', has a one-second connection timeout and a three-second total timeout, and does not follow redirects. Any redirect following happens inside the preview server, which is the behavior under test.

Our recorded command was python3 verify.py --output recorded-run. It exited successfully with {"checks": 12, "passed": true, "failures": []} plus the evidence path. That line means all twelve responses matched the expected outcomes, including the vulnerable and bypassed ones.

The run on 10 November 2026 used fixture and runner version 1.0.0, Python 3.15.2 and curl 8.7.1 on macOS ARM64. Exact runtime strings, UTC timestamps, commands, and source SHA-256 hashes are in results.json. A rerun will use different ports, timestamps, and response dates.

Establish positive and negative controls

Each mode received the same four requests. The first is a legitimate preview of the target article (positive control). The second asks for the metadata secret by the plain loopback address. The third asks for it by the decimal IP encoding. The fourth starts at the target site, which redirects to the metadata secret.

Observed preview-endpoint status and whether the secret leaked, from twelve local requests

The legitimate request returned 200 in every mode, so neither fix broke ordinary use. Naive mode blocked the literal address, but the secret still leaked through the two other request shapes.

Why blocking one hostname string fails

Naive mode in fixture.py rejects a request only when the parsed hostname string exactly matches one of 127.0.0.1, localhost or 0.0.0.0. It checks before it fetches anything:

if mode == "naive" and hostname in self.NAIVE_DENYLIST:
    return self.reply(403, {"reason": "denylisted_host", ...})

In the recorded run, the decimal-encoded request used this exact URL:

http://2130706433:55472/latest/meta-data/secret

The string 2130706433 is not in the denylist, so the check passes. Address resolution then turns that integer into 127.0.0.1 before the connection. The recorded response returned status 200 with "secret_leaked": true. Many resolvers also accept hexadecimal (0x7f000001) and short dotted (127.1) forms, and IPv6 has its own loopback and IPv4-mapped forms. A denylist of strings misses spellings it does not list. We did not test these other forms.

The redirect case is a second failure in the same mode. The request starts at http://target.test:55473/redirect, which the denylist does not flag. The target server answers with a 302 to the metadata URL. Naive mode's HTTP client follows the redirect automatically and does not run the hostname check again. The recorded response shows status 200 with the secret present. The check runs once, before the first hop, and nothing checks later hops.

Resolve, allowlist, and stop following redirects

Strict mode makes two changes. It resolves the hostname and checks the resolved (address, port) pair against an explicit allowlist. It also turns off automatic redirect handling in the HTTP client:

resolved_ip = resolve(hostname)
if (resolved_ip, port) not in self.server.allowlist:
    return self.reply(403, {"reason": "destination_not_allowlisted", ...})
opener = urllib.request.build_opener(NoRedirect)

The allowlist holds one entry, the target server's address and port. target.test on the target's port passes. The same IP on the metadata port fails, because the check uses the resolved address and port instead of the string the caller typed. With the redirect handler off, the 302 goes back to the caller and the server fetches nothing past the first hop. One gap remains. After the check, opener.open(url) resolves the hostname a second time, so the connection is not pinned to the address that was checked. A DNS name that changes its answer between the two lookups (DNS rebinding) could pass the check and connect elsewhere. The OWASP SSRF Prevention Cheat Sheet says to validate the resolved destination addresses and then make sure the HTTP client connects only to validated addresses. It also says to turn off redirect following in the client to prevent a bypass of input validation. For destinations known in advance, it recommends an allowlist, and it lists the hex, octal and dword encodings that defeat simple string checks.

The retest sent the same four requests to strict mode. The literal address and the decimal encoding both returned 403 with destination_not_allowlisted, in strict-literal.http and strict-encoded.http. The redirect request returned 200 with "upstream_status": 302 and an empty body, in strict-redirect.http. The preview endpoint reported the redirect and did not follow it. The legitimate article fetch still returned 200 with the article content.

Inspect the evidence bundle

• Machine-readable results: all twelve cases, modes, requested URLs, expected and observed outcomes, response filenames and hashes.

• Exact recorded curl commands: the ports refer to the finished run. Use the runner to create fresh servers.

• SHA-256 manifest: compare downloaded sources and evidence. This is an integrity check, not independent attestation.

• Fixture instructions and limitations, server source, and verification source.

The metadata value and the article are synthetic demo data. The bundle includes the raw HTTP response text, with dates and server headers. No production credentials or customer data were involved.

What this experiment does not cover

Twelve requests against three toy servers show one SSRF path and two bypasses of one naive defense. We did not test DNS rebinding (which the strict mode does not block, as noted above), hex, octal, IPv6 or IPv4-mapped forms, cloud metadata quirks, POST-based or webhook-style SSRF, out-of-band confirmation of blind SSRF, or production network segmentation. A fixture confined to loopback cannot show what a real internal boundary would stop. It shows that a check on the host string fails where a check on the resolved address holds, for these four requests.

For a real engagement, list every feature that accepts a URL, a hostname or anything used to build one: webhooks, importers, PDF or image renderers, link previews and SSO metadata URLs. Test each one with encoded addresses and with a redirect chain. The redirect bypass here overlaps with open redirect testing. A server that trusts an attacker-controlled Host header has a related failure, covered in host header injection. Authorization checks on the object itself are covered in authorization testing for APIs. Keep failed and inconclusive attempts with the successful ones, and rerun the same cases after each change to the fetching code.

Excession Labs tests outbound-request handling like this in its security assessments. See how a finding like this looks in a sample report. Download this finding written up as a one-page sample report (PDF).

Originally published at https://excessionlabs.ai/blog/ssrf/ . The test code and recorded output are there.