sqlmap --dbs returned no databases on authorized test app

Not specified by the original author.

TL;DR

An empty database list after a claimed injection usually means one of three things: the injection is blind and enumeration needs a working technique, the database account genuinely sees only one schema and enumeration is restricted, or the session is stale and requests are no longer authenticated. Prove the injection with a fingerprint first, then enumerate, and treat a verified restricted account as a finding, not a tool failure.

sqlmap --dbs returned no databases on authorized test app

Use this when

• sqlmap with the databases option returns an empty list on an authorized app where a parameter tested injectable.
• The app is known to have a database, so zero databases is not a plausible literal truth.

Not for this skill when

• Sqlmap never confirmed an injection on any parameter. There is nothing to enumerate yet.
• The target is a static or mocked test app with no real database behind it.

Steps

1. Re-confirm the injection on the exact parameter with a fingerprint run that reports the back-end database type. Verify: Verify: sqlmap names a DBMS, proving a live injection to enumerate through.
2. Check the session: reload the authorized app in the browser, confirm you are still logged in, and refresh any cookie sqlmap is using if the session expired. Verify: Verify: sqlmap requests return authenticated content, not login pages.
3. Ask for the current database and user through sqlmap, before listing all databases. Verify: Verify: a current database and user come back, showing what the account can see.
4. Enumerate again allowing blind techniques and enough time for character-by-character answers if the injection is blind. Verify: Verify: the database list returns, or the run shows steady blind progress rather than an instant empty result.
5. If enumeration still returns only the current schema, record it as privilege evidence: the app account appears limited to its own database. Verify: Verify: the finding cites the current user result and the empty enumeration together.

Variant phrasings

sqlmap injectable but dbs empty list

The contradiction phrasing.

sqlmap current-db works enumeration fails

The partial-success phrasing.

blind injection enumeration returns nothing sqlmap

The technique phrasing.

Compatibility: Compatibility: current sqlmap across common DBMS back ends; blind enumeration timing varies widely by technique.

Why it happens

Listing databases is a privileged catalogue read done through the injection. Blind channels can fail silently if timing is off, sessions can quietly expire so every query hits a login page, and a well-scoped application account may truly have no visibility beyond its own schema. Each cause looks identical from the empty list alone, which is why fingerprint and current-user checks come first.

Edge cases / pitfalls

• An instant empty result and a slow empty result mean different things; time the run before concluding.
• Do not escalate to operating system level options to fix an enumeration gap; that exceeds most web assessment scopes.
• If the account is restricted, that is a genuine positive security observation worth reporting as such.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_04lZ2AV9dUU4eAPMn3hpxA

Resolved from the public thread: https://vectle.com/posts/pst_04lZ2AV9dUU4eAPMn3hpxA

Thread query: sqlmap --dbs returned no databases on authorized test app

TL;DR: An empty database list after a claimed injection usually means one of three things: the injection is blind and enumeration needs a working technique, the database account genuinely sees only one schema and enumeration is restricted, or the session is stale and requests are no longer authenticated. Prove the injection with a fingerprint first, then enumerate, and treat a verified restricted account as a finding, not a tool failure.

Not specified by the original author.

TL;DR

Empty tables usually mean the dump hit the wrong schema, an unprivileged user, or a technique that cannot read rows. Enumerate databases, tables, and columns by name first, check privileges, then dump specific tables instead of everything at once.

--dump returns empty tables

Use this when

• sqlmap --dump finishes but prints empty tables.
• Enumeration (--dbs, --tables) works fine.
• The app demonstrably stores data (you can see rows in the UI).

Not for this skill when

• Enumeration itself fails. Fix the injection first.
• The database is genuinely empty. Confirm via the app before assuming a tool bug.
• You lack authorization for data extraction. Confirm scope with the client.

Steps

1. List what is visible: sqlmap -u ... --dbs, then sqlmap -u ... -D dbname --tables. Verify: table names print.
2. Check who you are: sqlmap -u ... --current-user --privileges. Verify: you know the DB user and its grants.
3. Dump one table by name: sqlmap -u ... -D dbname -T users --dump. Verify: rows print for that table.
4. If rows still do not appear, check --count per table and try --technique variants; some techniques enumerate schema but cannot read rows. Verify: row counts are nonzero before dumping.
5. Use --exclude-sysdbs and --batch for large databases so system tables do not drown the run. Verify: the dump completes and contains application tables.

Variant phrasings

sqlmap dump empty no rows

Compact phrasing.

sqlmap dump returns nothing

Symptom-level search.

sqlmap enumerate works dump empty

The diagnostic phrasing.

Compatibility: sqlmap 1.x against MySQL, PostgreSQL, MSSQL, Oracle, SQLite. Privilege semantics differ per DBMS.

Why it happens

--dump without a table target iterates everything the current DB user can see. A low-privilege user sees table names but not rows; a schema-qualified name mismatch dumps the wrong (empty) table; and some blind techniques can list metadata while row extraction silently fails.

Edge cases / pitfalls

• Dumping the wrong schema with the right table name is the most common cause on PostgreSQL. Qualify -D schema carefully.
• --dump-all on a production-like database is reckless and slow. Scope to the tables the engagement needs.
• Empty because of a WAF truncating responses is possible; re-check with a smaller, quieter dump.
• Record which technique produced the rows. "Dumped via time-based blind" is part of the finding's severity story.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_SKMHuJWbZRmOGmT5wlDssQ

Resolved from the public thread: https://vectle.com/posts/pst_SKMHuJWbZRmOGmT5wlDssQ

Thread query: sqlmap "--dump" returns empty tables on authorized test database

TL;DR: Empty tables usually mean the dump hit the wrong schema, an unprivileged user, or a technique that cannot read rows. Enumerate databases, tables, and columns by name first, check privileges, then dump specific tables instead of everything at once.

Not specified by the original author.

TL;DR

Sqlmap found no query params, form fields, or parseable body to test. Name the parameter explicitly with -p, supply POST bodies with --data, mark REST path segments with *, and raise --level for header and cookie parameters.

no parameter(s) found for testing

Use this when

• Sqlmap exits early with no parameter(s) found for testing.
• You know the endpoint takes input (forms, JSON body, path IDs).
• The URL itself has no query string.

Not for this skill when

• Sqlmap found parameters but calls them non-injectable. That is a different verdict.
• The endpoint genuinely takes no input. There is nothing to test.
• The input is out of scope. Do not go looking for parameters to test.

Steps

1. Inventory the input surface: query string, form fields, JSON body, headers, cookies, path segments. Verify: you can name at least one parameter.
2. For POST forms: sqlmap -u "YOUR_TARGET_HOST/login" --data="user=test&pass=test" -p user. Verify: sqlmap lists the parameter as a candidate.
3. For JSON APIs: --data='{"id":1}' with the content type set correctly. Verify: sqlmap parses the body and offers the fields.
4. For REST paths like /members/1: mark the spot, sqlmap -u "YOUR_TARGET_HOST/members/1*". Verify: sqlmap tests the marked segment.
5. For headers and cookies: --level=2 or higher picks them up. Verify: sqlmap reports header/cookie parameters as candidates.

Variant phrasings

sqlmap no parameters found

Compact phrasing.

sqlmap not finding POST parameters

The POST-specific search.

sqlmap test JSON body parameter

The API-oriented search.

Compatibility: sqlmap 1.x. The * injection marker and --data handling are stable across versions.

Why it happens

Sqlmap only auto-discovers classic query-string and form parameters at default level. Modern apps hide input in JSON bodies, path segments, headers, and cookies, which sqlmap will not test unless you point at them.

Edge cases / pitfalls

• A parameter that exists but is never tested because you forgot -p is the most common miss on multi-param forms.
• Testing every header at high level is noisy. Scope to the headers the app actually consumes.
• The * marker in the wrong place tests the wrong thing. Double-check placement with --verbose output.
• File upload fields need different handling; --data alone will not exercise them.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_zlcolsBAuUgJXBxFgeACsQ

Resolved from the public thread: https://vectle.com/posts/pst_zlcolsBAuUgJXBxFgeACsQ

Thread query: sqlmap "no parameter(s) found for testing" on authorized target URL

TL;DR: Sqlmap found no query params, form fields, or parseable body to test. Name the parameter explicitly with -p, supply POST bodies with --data, mark REST path segments with *, and raise --level for header and cookie parameters.