DEV Community: Victor Gutierrez Areyzaga

The Missing Check After Your Database Query

Victor Gutierrez Areyzaga — Thu, 25 Jun 2026 15:37:37 +0000

We have tools for checking whether a query is injectable. We have linters, scanners, ORMs, parameterized queries, and database policies. But after the database returns rows, most applications simply trust that the result set matches the operation that asked for it.

queryguard starts there.

The query may be safe. The result may still be wrong.

SQL injection taught us to distrust query construction. Parameterized queries answered the question:

Did the user control the query structure?

That question is well understood. The tooling is mature. But it is a different question from the one queryguard asks:

Did this operation receive only the rows and fields it was allowed to receive?

Those two questions are not the same. A perfectly safe parameterized query can still return the wrong row — because a predicate was dropped, a join widened the result, a developer selected a column they shouldn't have, or a query was rewritten without updating its scope contract.

queryguard is not a database firewall. It is not a SQL injection scanner. It is not an ORM plugin. It is a contract check for observed result sets.

Where it sits

The hook position is the core design decision. queryguard sits immediately after cursor execution — before any result shaping, filtering, serialization, or response mapping.

cursor = conn.execute(sql, bindings)
rows   = [dict(row) for row in cursor.fetchall()]

evidence = queryguard.run_check(contract, {
    "contract_id":      "user_profile_lookup",
    "contract_version": "0.1.0",
    "params":           {"user_id": user_id},
    "session":          {"tenant_id": tenant_id},
    "result":           rows,
})

if evidence["verdict"] != "PASS":
    raise QueryguardViolation(evidence)

return rows

Not at the HTTP layer. Not inside the ORM. Not at the API gateway. Immediately after the cursor returns rows — while the result is still raw, before anything shapes or discards it.

This is intentional. If rows are shaped before queryguard sees them, queryguard cannot detect violations in the discarded or modified data. The adapter-risk demo in the live lab shows this explicitly.

The contract

Each named operation has a contract that declares what its result set is allowed to look like.

id: user_profile_lookup
version: 0.1.0
operation: read
description: fetch one user profile by id

result:
  cardinality:
    max_rows: 1

  fields:
    allowed:
      - id
      - name
      - email
      - avatar_url
      - created_at
    required:
      - id
      - name
      - email
    forbidden:
      - password_hash
      - reset_token
      - mfa_secret

  row_constraints:
    required:
      - field: id
        operator: equals
        value_from: params.user_id

The contract declares intent, not SQL. queryguard never sees the query that ran. It only sees the contract and the result, and it asks: does the result match the declared scope?

The checks cover:

Cardinality — did the operation return the expected number of rows?
Field allowlist — does every row contain only declared fields?
Required fields — is every required field present?
Forbidden fields — did any sensitive field leak into the result?
Row constraints — does every row satisfy the declared predicates?

Each executed check produces a finding. Gateway checks can stop evaluation early when later checks would not be meaningful, but once the input envelope, contract, and result shape are valid, row and field checks run completely so multiple violations can be reported together. The evidence includes a contract_hash — a SHA-256 of the full contract body — so you can prove not just which contract identity was claimed, but which exact policy was applied. The evidence_hash then covers the contract body hash, the contract identity, the params, the session, and the result — so the record ties the observed rows to the exact policy used and changes when the verification inputs change.

The live DB proof

The real test is against real SQL. The live lab creates an in-memory SQLite database, seeds it with users, orders, and invoices, executes actual queries, and passes the raw cursor results to queryguard.

Nine cases:

Case	SQL	Verdict
Login clean	`WHERE email = ?`	PASS
Login tautology	`WHERE email = ? OR 1=1`	FAIL — cardinality, row_constraints
Profile clean	`WHERE id = ?`	PASS
Profile wrong row	`WHERE id = 2` with `params.user_id = 1`	FAIL — row_constraints
Profile forbidden column	`SELECT ... password_hash ...`	FAIL — field_allowlist, forbidden_fields
Orders clean	`WHERE customer_id = ?`	PASS
Orders missing predicate	`SELECT id, customer_id, status, total, created_at, updated_at FROM orders`	FAIL — row_constraints
Invoice clean	`WHERE id = ? AND tenant_id = ?`	PASS
Invoice missing tenant predicate	`WHERE id = ?` only	FAIL — row_constraints

Case 2 is the one worth pausing on. The query WHERE email = ? OR 1=1 returns every user in the database. The login contract says max_rows: 1 and email must equal params.email. queryguard catches the widened result on cardinality and row_constraints — before the application ever sees it.

Case 4 shows something different: the query is safe, the parameterization is correct, but the hardcoded predicate WHERE id = 2 returns the wrong row for params.user_id = 1. No injection. Clean SQL. Wrong result. queryguard catches it.

The adapter-risk demo shows the inverse: if SQL returns password_hash but an adapter strips it before queryguard sees the rows, queryguard returns PASS. The violation was hidden upstream. The rule is absolute — queryguard must sit before any shaping.

The honest limits

queryguard v0.1 is narrow by design.

Adapter shaping can hide violations. queryguard only verifies the rows it receives. If an adapter filters fields or rows before verification, queryguard cannot detect what was removed. The checker must run immediately after query execution and before any result shaping, filtering, serialization, or response mapping.

Row uniqueness is not enforced. Three identical authorized rows produce PASS, because every row satisfies the declared constraints. Detection of duplicate rows requires either a max_rows cardinality constraint or a future unique_by primitive.

Nested result rows are not verified. A row containing a nested object produces UNKNOWN. Flat rows only in v0.1.

Write operations are out of scope. No INSERT, UPDATE, DELETE. No result set, nothing to verify.

Aggregates are out of scope. COUNT, SUM, GROUP BY — row-level predicate enforcement requires individual rows.

Row order affects the evidence hash. The same logical result in a different order produces a different evidence_hash. Use a deterministic ORDER BY when reproducible hashes matter.

These are not oversights. They are the boundary of the one claim.

The test suite

The embedded suite has 59 cases across five batches:

Documented — clean reads, tautology injection, cross-user rows, forbidden columns, nested objects
Adversarial batches 1–4 — malformed contracts, hostile envelopes, null/bool coercion bypass, contract body substitution, cyclic structures, depth-exceeded values
Meta-tests — determinism, hash sensitivity to result changes, hash sensitivity to contract body changes, row-order behavior, duplicate-row known limitation, shared Python reference detection

The adversarial suite exists because a checker that catches bad results but crashes on bad inputs is not a reliable checker. The bounded JSON-domain walk handles depth > 64, node count > 10,000, and cyclic Python structures without crashing. Every failure returns structured evidence.

Why this matters — and where it should go next

SQL injection gave us decades of tooling for one side of the database boundary: the query going in. queryguard is an attempt at the other side: the result coming out.

It turns "I think this query returns the right data" into a testable, evidence-producing assertion. But v0.1 is narrow by design, and there are open questions I haven't fully answered yet.

What does the contract lifecycle look like at scale? Right now contracts are simple versioned operation definitions, treated as immutable once published. That works for a lab. It gets harder when a schema changes and fifty contracts need updating. How do teams manage that without the manifest going stale?

Where should this live in a real pipeline? I've placed it at the cursor boundary, immediately after rows are returned. In real applications, the nearest practical hook might be a repository layer, database access wrapper, or ORM-adjacent interception point — but the rule stays the same: verify before shaping, filtering, serialization, or response mapping.

Is the one-thing discipline the right call for v0.2? Row uniqueness, nested rows, and write authorization are explicitly out of scope. Each could become its own tool in the same family. But maybe the right move is a more complete result verifier rather than three separate tools. I genuinely don't know yet.

If you've hit similar gaps — results you couldn't trust, predicates that got dropped, columns that leaked into responses — I'd like to hear how you've handled it. And if you run the suite or the live lab and find something that should fail but doesn't, open an issue.

The scope is narrow. The claim is specific. That's where v0.1 has to start.

queryguard v0.1 — github.com/rodrigo-areyzaga/queryguard

Single file. Zero dependencies. python queryguard.py to run the suite. python live_db_lab.py for the SQLite validation.

The Tool Found Corridor Nodes — But the Bigger Finding Was Where It Found None

Victor Gutierrez Areyzaga — Tue, 23 Jun 2026 15:36:00 +0000

A few weeks ago I published corridor-lab — a Docker lab that proved a triage mismatch: a service that stores nothing sensitive can become high-priority because of where it sits in the path to a sensitive downstream system.

The lab proved the premise. The next question was whether a tool could identify those nodes automatically — without manual path declaration, without value labels, from graph position alone.

So I built corridor-id. You point it at a Docker Compose file. It discovers the topology, computes depth from exposed surfaces, and identifies which nodes expand forward reach into deeper parts of the environment. No asset-value labels. No sensitivity ratings. No human classification. Reach and graph position only.

Then I pointed it at four architecturally different Docker environments.

Two had corridor nodes. Two had none.

Both answers were useful. But the zero-corridor results taught me more than the positive ones.

What corridor-id does

The tool reads a Docker Compose file and builds a reachability graph from service definitions, network memberships, and port mappings. It then orients that graph from exposed surfaces using BFS and identifies nodes that provide forward reach — access to strictly deeper nodes that the exposed surface cannot reach directly.

The output is a ranked list with two metrics: exposure distance (how close to the surface) and forward reach gain (how many deeper nodes become reachable through this node).

One command:

python corridor-id.py docker-compose.yml

No manual path declaration. No value labels. No configuration. From graph position alone.

The four tests

corridor-lab — segmented, depth 3

My own lab, five services across five segmented networks. The tool independently identified status-api as a corridor node — the same finding the lab was built to prove.

Corridor nodes found: 3

  → status-api
    Exposure distance: 1
    Forward reach gain: 1

  → log-monitor
    Exposure distance: 1
    Forward reach gain: 1

  → internal-admin-api
    Exposure distance: 2
    Forward reach gain: 1

This was validation that the tool's graph logic matched the lab's manual analysis.

Sock Shop — segmented test variant, depth 3

Weaveworks' microservices demo with production-reasonable network segmentation applied for analysis. The segmentation is not how the original Compose file ships. The point was not to claim Sock Shop is segmented by default — the point was to test whether corridor-id could identify corridor nodes when meaningful network depth exists. Fifteen services, seven networks.

Corridor nodes found: 6

  → front-end
    Exposure distance: 1
    Forward reach gain: 6

  → orders
    Exposure distance: 2
    Forward reach gain: 3

  → shipping
    Exposure distance: 2
    Forward reach gain: 2

front-end ranked first because it bridges the edge tier into six application services. orders ranked second because it bridges the app tier into both a data tier and a queue tier — disproportionate reach for a single service. The tool surfaced these findings without knowing what any service does.

OWASP crAPI — flat, no segmentation

Ten services. One default network. Every service can reach every other service.

Corridor nodes found: 0

Docker Example Voting App — segmented-looking but flat in practice

Five services. Two networks. But both exposed services sit on both networks.

Corridor nodes found: 0

What the zero-corridor results actually mean

My first instinct when crAPI returned zero corridor nodes was that the tool had nothing to say about it. No finding. Nothing to report.

That instinct was wrong.

crAPI returned zero corridor nodes because it has no network segmentation. All ten services share one default network. There are no corridors because there are no walls. Every service is already reachable from every other service.

The voting app was subtler. It has two named networks — front-tier and back-tier — which looks like segmentation. But both exposed services (vote and result) sit on both networks. So the back-tier services are all directly reachable from the exposed surface at depth 1. The segmentation exists in the Compose file but doesn't create depth.

The tool correctly identified both cases. It didn't just fail to find corridor nodes — it surfaced that the architecture lacks the conditions for corridor nodes to exist.

In a segmented topology, corridor-id finds corridor nodes.

In a flat topology, corridor-id finds something different: there are no corridors because there are no meaningful zones. That is not a clean bill of health. A zero-corridor result has two meanings. In a well-segmented topology, it may mean no node expands reach — genuinely low corridor exposure. In a flat topology, it means the corridor model collapsed because everything is already in the same reachability zone.

The distinction that matters

Corridor topology: some nodes control movement between zones. Those are corridor nodes and they deserve monitoring proportional to their reach.

Flat topology: there are no meaningful zones, so there are no corridor nodes. But the absence of corridors means every service sits in the same reachability zone. The path problem doesn't go away — it becomes universal.

The tool can distinguish between these two conditions. That distinction is, I think, the more interesting finding.

What corridor-id does not claim

The four environments I tested are demo and security training applications — not production systems. The flat-network pattern was common in these samples, but I'm not claiming that "most containerized applications in the wild" lack segmentation. I'm saying that in the containerized architectures I tested, flat networking was common enough that the absence of corridor nodes became its own finding.

The tool also has known limitations: it computes a global depth map across all exposed nodes (which can suppress per-entry corridor findings), it treats localhost-bound ports as exposed, and it doesn't filter Compose profiles. All documented in the repo.

This is a v0.2 tool with a narrow promise: given a topology, identify which nodes are corridor nodes. It does that one thing.

The through-line

accguard tests whether authorization boundaries hold under replay.

corridor-lab proves that a service's risk depends on where it sits in the path, not what it stores.

corridor-id identifies corridor nodes from topology — automatically, from graph position alone.

Each one asks the same question at a different layer: does the security posture match what the architecture actually allows?

The repo

github.com/rodrigo-areyzaga/corridor-id

git clone https://github.com/rodrigo-areyzaga/corridor-id
cd corridor-id
pip install pyyaml
python corridor-id.py your-docker-compose.yml

The core topology model is format-agnostic and has been validated against hand-built topologies with no parser involved. Docker Compose is the first input adapter. The identifier logic doesn't know or care where the topology came from.

A note on how this was built

corridor-id was developed with AI assistance. Claude and ChatGPT were used as pair-programming and review tools — for implementation, stress-testing edge cases, and catching two parser bugs before release. The concept, security framing, testing direction, and all accept/reject decisions were human-directed.

I'm still exploring this. The harder question — how to move from topology analysis to detection triggers on corridor nodes — is the next problem. If you've thought about it, or if you think the framework is wrong, I'd like to hear it.

The Service That Stored Nothing Sensitive But Still Became High Priority

Victor Gutierrez Areyzaga — Thu, 18 Jun 2026 15:26:50 +0000

I kept noticing a mismatch between how defenders prioritize assets and how attackers actually move through environments.

The standard model goes like this: classify your assets by what they contain — customer data, credentials, financial records — and allocate your hardening and monitoring effort proportionally. Crown jewels get the most attention. A health-check service with no sensitive data gets the minimum.

The problem is that attackers don't move through environments the way this model assumes. They often do not target the most valuable asset first. They target the most useful reachable path. And that path often runs through something that received less hardening, less monitoring, or less ownership precisely because it looked unimportant on its own.

So I built a small Docker lab to test whether the scoring model was the problem — and whether switching from value-indexed to path-indexed triage changed the answer for the same asset in the same environment.

It did. Significantly.

The core distinction

Before the lab: two ways of scoring an asset.

Value-indexed triage asks: what does this asset directly contain?

A database with customer PII scores high. A status service with no stored data scores low. The score reflects the asset's direct data classification.

Path-indexed triage asks: what can this asset help an attacker reach?

A status service with no stored data but with internal reach to a privileged API scores high — not because of what it holds, but because of where it sits in the environment. Its position in the graph is what matters.

The asset I wanted to test this against is what I started calling a corridor node: a service that appears low-priority under data classification but becomes high-priority because it sits between an exposed entry point and a sensitive downstream system.

The lab topology

Five services. One corridor node. One monitoring blind spot.

[public-web]          ← internet-facing entry point
     |
     v
[status-api]          ← corridor node
     |
     v
[internal-admin-api]  ← high-value control plane
     |
     v
[customer-db]         ← sensitive asset

[log-monitor]         ← collects logs from public-web and internal-admin-api
                        does NOT collect logs from status-api

Each service is a minimal Python/Flask application. The Docker Compose networks enforce the topology structurally — not just in application code. public-web has no direct network path to internal-admin-api or customer-db. The only route is through status-api.

The corridor node: status-api

Under value-indexed triage, status-api scores low. It stores no customer data. It holds no credentials. It owns no business-sensitive records. It is an internal health-check service — uptime, version info, basic diagnostics.

The scoring model looks at what it contains and concludes: low priority. Minimal hardening. No monitoring assigned. Not included in the threat model.

Under path-indexed triage, status-api scores high — because of what it can reach.

It was connected to internal-admin-api during a diagnostic build. Engineering needed it to relay health checks and system status. The connection made sense at the time. It was never reviewed for security posture because the service itself was classified as low-priority. Why audit a health-check service?

That decision is what makes it a corridor node.

Running the proof

One request to public-web/status triggers the full chain:

curl http://localhost:8080/status

The response:

{
  "source": "public-web",
  "diagnostic": {
    "source": "status-api",
    "system_check": {
      "source": "internal-admin-api",
      "records": [
        {"id": "C-001", "name": "Ana Torres", "email": "a.torres@example.com",
         "account_type": "premium", "balance": 14200.0},
        {"id": "C-003", "name": "Elena Voss", "email": "e.voss@example.com",
         "account_type": "premium", "balance": 98100.5},
        {"id": "C-005", "name": "Priya Nair", "email": "p.nair@example.com",
         "account_type": "enterprise", "balance": 340000.0},
        {"...": "additional records omitted for brevity"}
      ]
    }
  }
}

Customer records — names, emails, account types, balances — returned through a single request to the internet-facing entry point. The external client never addressed internal-admin-api or customer-db directly. The downstream access was created by the application path itself, and that path ran through the asset the value-indexed model marked as lowest priority.

Finding 1 — Triage mismatch

The side-by-side comparison:

Asset	Value-indexed	Path-indexed	Delta
customer-db	CRITICAL	CRITICAL	none
internal-admin-api	HIGH	HIGH	none
public-web	MEDIUM	MEDIUM	none
status-api	LOW	HIGH	← mismatch

status-api was scored LOW because it stores nothing sensitive.

status-api scores HIGH because of where it sits in the path.

The mismatch is the finding. Same asset, same environment, different scoring model, different priority, different outcome. Under value-indexed triage, status-api receives minimal hardening and no monitoring. Under path-indexed triage, it enters the threat model immediately.

Finding 2 — Detection mismatch

This is the part that surprised me most when the lab ran.

After the request completes, log-monitor reports:

[public-web] — 1 event(s) logged
  GET /status from 172.23.0.1 — triggering diagnostic workflow

[internal-admin-api] — 1 event(s) logged
  GET /system-check — fetching records from customer-db

[status-api] — NOT IN MONITORING SCOPE
!! status-api activity is not captured
!! path reconstruction from public-web to internal-admin-api is impossible
!! an attacker traversing this corridor leaves no trace here

Two events. One at the entry point, one at the control plane. Nothing in between.

An analyst reviewing this output would see a request come in and records go out — with no explanation of how they connected. The corridor hop is invisible. The path cannot be reconstructed after the fact.

This is the second failure. The first failure was the triage model that left status-api unmonitored. The second failure is what that decision costs during an investigation.

A control can fail twice: first when it allows a path, and again when monitoring cannot explain that path after it is used.

What this does not claim

This lab is an existence proof, not a prevalence claim.

It does not argue that corridor nodes are common in all environments. It proves that an asset can be mis-prioritized when classification ignores reachable downstream impact. One environment, one corridor node, one falsifiable claim.

The lab is also intentionally unsophisticated. There is no novel exploit technique here. No clever bypass. The attacker path is almost boring — a request triggers a diagnostic workflow that relays to an internal API. The point is not what the attacker did. The point is what the scoring model failed to notice.

This lab also does not compete with enterprise attack path management platforms. Tools in established categories like attack path management, continuous threat exposure management, and application dependency mapping address versions of this problem at scale. What this lab does differently is make the reasoning visible in a reproducible five-minute proof — small enough to run locally, clear enough to argue with.

Why this matters

Security triage is a resource allocation problem. Where you spend hardening effort, monitoring instrumentation, and ownership assignment is a prioritization decision. That decision is often influenced by value-indexed thinking — the more sensitive the data, the more attention the asset gets.

Attackers don't use this model. They use path-indexed thinking. They look for the weakest reachable node, not the most valuable one. And the weakest reachable node is often one that scored low on your triage model — because that low score is exactly why it received less hardening, less monitoring, and less ownership.

The mismatch between where defenders invest and where attackers move is not a resource problem. It is a prioritization model problem.

Switching the question from "what does this asset contain?" to "what can this asset help an attacker reach?" changes which assets demand attention — and changes it for the assets that are currently getting the least.

Limitations

The lab models application-layer logging, not network-layer traffic analysis. A network monitoring tool with full packet capture would see the status-api hop. The detection gap demonstrates a logging coverage failure, not an absolute invisibility claim.
log-monitor shares a network segment with internal-admin-api for log collection purposes. The lab does not model endpoint-level authorization on the monitoring plane — the corridor finding focuses on the public-web → status-api → internal-admin-api path.
One corridor node in one synthetic environment is an existence proof. The framework needs real-environment validation to make prevalence claims.

The repo

The full lab is on GitHub: github.com/rodrigo-areyzaga/corridor-lab

git clone https://github.com/rodrigo-areyzaga/corridor-lab
cd corridor-lab
docker compose up --build

In a second terminal:

python triage-report.py

The triage report runs both scoring models, triggers the live path, and walks through the falsifiability checks. The monitoring gap can be observed through the log-monitor output. The full chain takes under a minute to run from a cold start.

A note on how this was built

This lab was developed through an AI-assisted workflow. I used Claude and ChatGPT as pair-programming and review tools throughout — for implementation, for challenging claims, and for successive review passes before publication.

I'm noting that explicitly because it matters to how you read the work. The concept, the security framing, the constraint decisions, the local testing, and every accept/reject call on what went into the final lab were human-directed. The question that produced the lab — whether switching from value-indexed to path-indexed triage changes the answer for the same asset — was the creative act. The AI tools helped make that question executable.

This is also how a lot of real work gets done. Naming it seems more useful than obscuring it.

I'm publishing this as a question as much as a finding. If you've thought about this problem — or if you think the framework is wrong — I'd genuinely like to hear it.

The harder question, which the lab doesn't answer, is how you build the reachability map in a real environment efficiently enough to be useful. That's the next problem.