## TL;DR
The heuristic phase is conservative by design; "might not be injectable" is sqlmap's opinion after a cheap check, not a verdict. Confirm the parameter actually reaches the app, then force full testing with explicit level, risk, and parameter selection. Verify manually with a benign boolean or time check before trusting the negative.

```text
heuristic (basic) test shows that GET parameter might not be injectable
```

## Use this when
- Sqlmap warns the GET parameter might not be injectable on an in-scope app.
- The parameter clearly reaches application logic (it changes the page or query).
- You want to rule out a false negative before moving on.

## Not for this skill when
- The parameter returns byte-identical content for every input. That is genuinely not injectable via that vector.
- You have already run full level/risk tests and found nothing. Accept the negative.
- The parameter is out of scope. Do not test it regardless of injectability.

## Steps
1. Confirm the parameter reaches the app: request the URL with two different values and diff the responses. Verify: the page content changes with the parameter.
2. Force the test explicitly: `sqlmap -u "YOUR_TARGET_HOST/page?id=1" -p id --level=3 --risk=2`. Verify: sqlmap runs the full payload list instead of stopping at the heuristic.
3. Manually verify with a benign check first: `id=1 AND 1=1` vs `id=1 AND 1=2`, or a short SLEEP payload, and compare. Verify: you see a content or timing difference yourself.
4. If the app filters aggressively, try `--technique=B` (boolean) alone before time-based. Verify: boolean differences appear before you spend time on slow tests.
5. Document the false negative: the warning text plus the command that overrode it. Verify: the engagement notes record both.

## Variant phrasings
### sqlmap heuristic test false negative
Shorter phrasing of the same warning.
### sqlmap says parameter not injectable but it is
How testers phrase it after manual confirmation.
### sqlmap heuristic basic test GET parameter
The keyword-heavy search.

Compatibility: sqlmap 1.x. Heuristic behavior is stable across recent versions; `--level`/`--risk` semantics unchanged.

## Why it happens
The heuristic runs a tiny set of probes and bails early to save time. Apps with heavy filtering or cached responses look static to those few probes even when a real injection exists deeper in the payload space.

## Edge cases / pitfalls
- A cached response can fake a negative. Bust the cache with a random query value before concluding anything.
- Forcing `--risk=3` on a production-adjacent target can damage data. Stay within the engagement's agreed risk level.
- The heuristic can also be RIGHT. If manual checks show no difference, move on; do not burn the engagement window on a dead parameter.
- Log the exact command that overrode the heuristic. A claim without the command is not evidence.

## Provenance

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