Sast SqliSAFE
Collection of agent skills to find vulnerabilities inside your web/mobile apps.
Overview
Collection of agent skills to find vulnerabilities inside your web/mobile apps.
d9c848ebb5f1OBSERVED · 2026-10-13Host compatibility
What the documentation claims. We have not run a compatibility test.
| Host | Status | Notes |
|---|---|---|
| cursor | mentioned |
What it tells the agent
The instruction file, verbatim from the audited commit — this is the text the model reads, and the surface the audit's instruction layer examines. Quoted here so you can judge it without cloning anything.
---
name: sast-sqli
description: >-
Detect SQL injection vulnerabilities in a codebase using a three-phase approach:
recon (find unsafe SQL construction sites), batched verify (trace user input to
those sites in parallel subagents, 3 sites each), and merge (consolidate batch
results). Covers string concat, f-strings, unsafe ORM methods, and dynamic
identifiers. Requires sast/architecture.md (run sast-analysis first). Outputs
findings to sast/sqli-results.md. Use when asked to find SQLi or database
injection bugs.
---
# SQL Injection (SQLi) Detection
You are performing a focused security assessment to find SQL injection vulnerabilities in a codebase. This skill uses a three-phase approach with subagents: **recon** (find vulnerable SQL construction sites), **batched verify** (taint analysis in parallel batches of 3), and **merge** (consolidate batch reports into one file).
**Prerequisites**: `sast/architecture.md` must exist. Run the analysis skill first if it doesn't.
---
## What is SQL Injection
SQL injection occurs when user-supplied input is incorporated into SQL queries through string concatenation or interpolation rather than parameterized binding. This allows attackers to alter query logic, bypass authentication, extract sensitive data, modify or delete records, and in some configurations execute OS commands.
The core pattern: *unvalidated, unparameterized user input reaches a SQL query execution call.*
### What SQLi IS
- Concatenating user input directly into a SQL string: `"SELECT * FROM users WHERE name = '" + username + "'"`
- Using string formatting to build queries: `f"SELECT * FROM orders WHERE id = {order_id}"`
- Dynamic `ORDER BY` / `GROUP BY` / table/column names from user input with no allowlist validation
- ORM raw query methods with unsanitized input: `User.objects.raw(f"SELECT * WHERE id={id}")`, `$queryRawUnsafe(input)`
- Second-order injection: input is stored in the DB and later used in a raw query without re-sanitization
### What SQLi is NOT
Do not flag these as SQLi:
- **IDOR**: Changing `?id=1` to `?id=2` to access another user's data — that's Insecure Direct Object Reference, a separate class
- **Mass assignment**: Setting extra ORM model fields from user input — different vulnerability
- **XSS via database**: Storing a `<script>` tag in the DB that's later rendered unescaped — that's XSS, not SQLi
- **NoSQL injection**: Injecting into MongoDB operators — similar concept but a distinct vulnerability class
- **Safe ORM queries**: Parameterized ORM lookups like `User.objects.filter(id=user_id)` or `User.find(params[:id])` — do not flag these
### Patterns That Prevent SQLi
When you see these patterns, the code is likely **not vulnerable**:
**1. Parameterized queries / prepared statements (most common fix)**
```
# Python — cursor.execute with tuple binding
cursor.execute("SELECT * FROM users WHERE id = %s", (user_id,))
# Node.js — mysql2 / pg placeholder binding
db.query("SELECT * FROM users WHERE id = ?", [userId])
pool.query("SELECT * FROM users WHERE id = $1", [userId])
# Java — PreparedStatement
PreparedStatement ps = conn.prepareStatement("SELECT * FROM users WHERE id = ?");
ps.setInt(1, userId);
# Go — database/sql placeholder
db.QueryRow("SELECT * FROM users WHERE id = $1", userID)
# PHP — PDO with named params
$stmt = $pdo->prepare("SELECT * FROM users WHERE id = :id");
$stmt->execute(['id' => $userId]);
# C# — SqlCommand with parameters
cmd.CommandText = "SELECT * FROM users WHERE id = @id";
cmd.Parameters.AddWithValue("@id", userId);
```
**2. ORM query builder (safe by default)**
```
# Django ORM
User.objects.filter(id=user_id)
# ActiveRecord (Rails)
User.find(params[:id])
User.where(name: params[:name])
# Prisma (tagged template literal form of $queryRaw)
await prisma.$queryRaw`SELECT * FROM users WHERE id = ${userId}`
# Laravel Eloquent (non-raw)
User::find($id)
```
**3. Allowlist validation for dynamic identifiers**
```
# Dynamic ORDER BY — validate column name against a hardcoded set before interpolating
ALLOWED_COLUMNS = {'name', 'created_at', 'price'}
if sort_col not in ALLOWED_COLUMNS:
raise ValueError("Invalid column")
query = f"SELECT * FROM products ORDER BY {sort_col}" # safe only after allowlist check
```
---
## Vulnerable vs. Secure Examples
### Python — Django (raw SQL)
```python
# VULNERABLE: f-string interpolation in raw()
def search_users(request):
username = request.GET.get('username')
users = User.objects.raw(f"SELECT * FROM auth_user WHERE username = '{username}'")
return JsonResponse(list(users.values()), safe=False)
# SECURE: parameterized raw()
def search_users(request):
username = request.GET.get('username')
users = User.objects.raw("SELECT * FROM auth_user WHERE username = %s", [username])
return JsonResponse(list(users.values()), safe=False)
```
### Python — Flask / SQLAlchemy
```python
# VULNERABLE: f-string into text()
@app.route('/search')
def search():
name = request.args.get('name')
result = db.session.execute(text(f"SELECT * FROM products WHERE name = '{name}'"))
return jsonify(result.fetchall())
# SECURE: named bound parameter
@app.route('/search')
def search():
name = request.args.get('name')
result = db.session.execute(
text("SELECT * FROM products WHERE name = :name"), {"name": name}
)
return jsonify(result.fetchall())
```
### Python — sqlite3 / psycopg2
```python
# VULNERABLE
def get_user(username):
cursor.execute("SELECT * FROM users WHERE username = '" + username + "'")
return cursor.fetchone()
# SECURE
def get_user(username):
cursor.execute("SELECT * FROM users WHERE username = ?", (username,))
return cursor.fetchone()
```
### Node.js — mysql2
```javascript
// VULNERABLE: template literal in query string
app.get('/user', async (req, res) => {
const { id } = req.query;
const [rows] = await db.query(`SELECT * FROM users WHERE id = ${id}`);
res.json(rows);
});
// SECURE: placeholderTrust audit
SAFEgrade B · trust 89/100 Nothing in the source contradicts what it says it does. Grade A is reserved for packages that have also passed the behavioural sandbox.
| Layer | What it checks | Result |
|---|---|---|
| L0 | Provenance & inventory | PASS |
| L1 | Static analysis of the code | NA |
| L2 | Instruction surface (what it tells the agent) | PASS |
| L3 | Class-specific surface | PASS |
| L4 | Behavioural (sandbox) | SKIPPED |
What the source does
- Filesystem
- none-observed
- Network
- none-observed
- Shell
- none-observed
- Dependencies
- pinned
- Secrets in source
- none-found
Findings (0)
No findings outside the package's declared scope.
Gates applied: no_behavioural_pass.
d9c848ebb5f1full audit observations/trust-audit/skill/utkusen__sast-sqli.json · Report an issue / request a re-scanAudit history
Every audit this skill has had.
| Date | Source | Verdict | Grade | Score | Change |
|---|---|---|---|---|---|
| 2026-10-13 | d9c848ebb5f1 | SAFE | B | 89 | first audit |
Questions
What does the Sast Sqli skill do?
Collection of agent skills to find vulnerabilities inside your web/mobile apps.
Is Sast Sqli safe to install?
The audit found nothing in the source that contradicts what it says it does, and graded it B (89/100). Grade A is held back for packages that have also passed a sandboxed behavioural run, which is why a clean skill reads B.
What can Sast Sqli access on my machine?
The audit observed no filesystem, network or shell use at all in its source.
Which assistants does Sast Sqli work with?
Its documentation mentions cursor. That is what the text claims, not a compatibility test we ran.
How current is this page?
The grade is for one exact copy of the source (d9c848ebb5f1), read on 2026-10-13. The repository is watched, and a new audit runs when it changes — this is the first audit.