Risk Breakdown · OWASP Critical

The classic bugs that turn a launch into a breach.

SQL injection, command injection, XSS, SSRF, and unsafe deserialization are not exotic. They are the everyday ways a working app hands an attacker the keys: read the whole database, run shell commands on your box, run scripts in your users' browsers, or make your server attack your own internal network. IOnclad reads your code as a real syntax tree, not a pile of text, and follows where user input actually goes.

What the Top 10 actually covers

OWASP groups the most common ways web apps get owned. IOnclad's web scanner maps its checks against that list, and these are the categories it digs into the hardest:

It parses real grammars for JavaScript, TypeScript, Python, Java, Go, Ruby, and PHP. When a file is in a language it does not have a grammar for, it falls back to a line-level regex pass so nothing goes completely unscanned.

Why these bugs are so dangerous

Every one of these is the same story: untrusted input reaches a place it was never supposed to control. The damage just depends on the place.

1. Injection: the input becomes the instruction

When user input is glued into a SQL string, a shell command, or an eval(), the attacker stops being a user and starts being the author. A single ' OR 1=1 -- dumps the users table. A ; rm -rf in a filename runs on your server. IOnclad flags .query(), .execute(), exec(), os.system, Prisma's $queryRawUnsafe, Knex raw builders, and more when tainted input flows in.

2. XSS: your page runs the attacker's script

An innerHTML assignment, a document.write(), or a React dangerouslySetInnerHTML built from user content lets an attacker run JavaScript in your visitors' sessions: steal tokens, hijack accounts, rewrite the page. IOnclad checks the left-hand side and the actual value, so it does not scream about a static JSON-LD block or a hardcoded constant.

3. SSRF: your server becomes the attacker's proxy

If a request URL is built from user input, an attacker can point your server at 169.254.169.254 and read cloud metadata, or scan your private network from inside. IOnclad checks the first (URL) argument of fetch, axios, got, http.request, and Python requests for taint, and it knows a fixed URL with a user-controlled body is not SSRF.

4. Unsafe deserialization: data that runs code

Python pickle.loads, yaml.load without a safe loader, and Node node-serialize on untrusted bytes are straight-up remote code execution. The payload looks like data and behaves like a program. IOnclad only fires when the file actually imports a known-dangerous deserializer, so it does not flag every function named deserialize.

The shape of a real incident

Injection almost always ships in code that looks completely normal:

# Looks fine. Tests pass. The query "works."
const user = await db.query(`SELECT * FROM users WHERE id = ${req.params.id}`);

# A regex grep sees ".query(" + a backtick and either fires on EVERY
# template literal (even static CREATE TABLE strings) or misses this
# one because it's wrapped: await retry(() => db.query(...)).

const user = await db.query('SELECT * FROM users WHERE id = $1', [req.params.id]);
# Parameterized. The id is data now, never instruction. ✓

How to fix it

• Parameterize every query. Use placeholders ($1, ?, :param, %s with a params tuple). Never build SQL with string interpolation or concatenation, even into a separate variable first.
• Never shell out with user input. Use execFile or spawn with an argument array, or subprocess.run([...], shell=False). Drop eval() entirely.
• Escape on output for XSS. Use textContent, and sanitize with DOMPurify when you genuinely need to render HTML. Validate URLs and reject javascript: and data: schemes.
• Allowlist outbound URLs to stop SSRF, and block requests to private IP ranges (10.x, 172.16-31.x, 192.168.x, 169.254.x).
• Use safe deserializers. Prefer JSON. Use yaml.safe_load(), never raw pickle on untrusted data.