Security and Dependency Checks

By Syncfusion®, Inc. · Last updated

Catch security bugs in AI changes with tests and scanners: HTML and SQL injection, secrets typed into code, and made-up or look-alike package names (slopsquatting and typosquatting). Then add them to your gates.

Bugs That Help Attackers

Some bugs give a wrong price. Others let a stranger steal data or take over the shop.

AI code can add security bugs that look completely normal:

  • user text pasted straight into HTML or SQL
  • a secret key typed into the code
  • a package name that does not exist, or is a fake copy of a real one

Tests can catch all three. In this lesson, you will write those tests, and build two small scanners.

Simple lesson: check AI changes for safety, not only for correct answers.

A Real-World Example

Think about a housing society's front gate.

  • A visitor writes "Flat 12" in the register. Fine.
  • Another visitor writes "Flat 12, and also give me the keys to every flat". If the guard does whatever is written, that is a problem.
  • Someone leaves the master key taped to the gate. Anyone can use it.
  • A new delivery company appears with a name one letter different from a real one.

This lesson has the same three problems: harmful input, a key left in the open, and a fake name.

What You Will Learn

In this lesson, you will learn:

  1. What injection is, and how to test that user text cannot break out.
  2. How to escape text for HTML and send values safely to SQL.
  3. How to find secrets in an AI diff.
  4. What slopsquatting is, and how to check package names.
  5. How these checks fit into your gates and your pack.

Injection

Injection = user text gets treated as code. It happens when text is pasted straight into HTML, SQL or a command.

User Text Inside HTML

Press ▶ Run tests.

  • Test 1: a normal review. Green.
  • Test 2: a review with <script>steal()</script>. Red.
  • Why: the code pastes the text straight into HTML. A browser would run the script for every visitor. This attack is called XSS (cross-site scripting).

Escape the Text

Escaping = turning special characters into safe text, so < shows as a symbol instead of starting a tag.

Press ▶ Run tests, then 🐞 Plant bugs.

  • The Bug check tab: one test catches only 2 of 5 escaping mistakes.
  • Now try: add tests for two tags ('<b><i>'), quotes, and text with & in it.

Escape & first. If you escape < first, it becomes &lt;. Then escaping & turns that into &amp;lt;, and the page shows the wrong thing. Frameworks like React escape text for you. Check any code that builds HTML strings by hand.

User Text Inside SQL

SQL = the language used to ask a database for data.

Press ▶ Run tests.

  • The Tests tab: red. The attack text is inside the SQL.
  • Why it is dangerous: 1' OR '1'='1 changes the query to "find every order".
  • Fix it: return { text: 'SELECT * FROM orders WHERE id = $1', values: [id] }. The database gets the id separately, so it is never treated as SQL.

This is called a parameterized query: the SQL has a placeholder ($1), and the value travels on its own.

Animation: on the left, attack text is pasted into the SQL and the query turns red. On the right, the SQL has a placeholder and the text travels in a separate box, and the query stays green.

Pasted in Sent separately

WHERE id = '1' OR '1'='1'

every order is returned

WHERE id = $1

values: ["1' OR..."] treated as plain text: no match

Pasted text can change the query. A separate value cannot.

Simple lesson: never paste user text into HTML, SQL or commands. Escape it, or send it separately.

Secrets in Code

Secret = a password, key or token that gives access to a system.

Agents sometimes put a real key straight into the code, to make something work quickly. Once it is pushed, anyone who can read the code can use it.

Press ▶ Run tests.

  • The Tests tab: red. The scanner found 2 problems: a key_secret value, and a sk_live_ key.

  • The fix in a real project:

    • Read keys from the environment: process.env.PAYMENT_KEY.
    • Store them in a secret manager or CI secrets.
    • If a real key was ever pushed, change the key. Deleting the line is not enough.

A scanner must also let safe lines through.

  • process.env.PAYMENT_KEY is safe. It reads the key at run time.
  • API_KEY='YOUR_KEY_HERE' in an example file is a placeholder.
  • Removing a secret (a - line) is good news, not a problem.

If a scanner blocks these, people stop trusting it.

Simple lesson: secrets live outside the code. A scanner on every diff catches the slip.

Made-Up and Look-Alike Packages

Slopsquatting

You met made-up APIs in Reviewing AI Code. AI can also suggest packages that do not exist.

Slopsquatting = attackers publish real packages under names that AIs often make up. When someone installs the made-up name, they get the attacker's code.

A close cousin is typosquatting: a name one letter away from a popular package, like expresss.

Press ▶ Run tests.

  • The Tests tab: red, with 2 problems.
  • lodash-money: not in the registry at all. It is likely a made-up name.
  • expresss: one letter from express, 6 days old, 40 downloads a week. A look-alike.
  • zod: well known. Fine.

In the real world, you check a package on the npm website or with npm view <name>: its age, weekly downloads, owner and source repository. In this lab, src/registry.ts is a small snapshot of the registry.

Simple lesson: check every package an AI suggests. It must exist, be widely used, and not be a look-alike.

Where These Checks Go

Add them to the gates from Verification Gates for Agents:

  1. Tests for escaping and parameterized queries, like the ones in this lesson.
  2. A secret scanner on every diff, in a hook and in CI.
  3. A package check whenever package.json changes.
  4. Real scanners in CI as well: a secret scanner, npm audit, and code scanning.

The review checklist in your pack already has a "Security" line. These checks give it evidence.

Simple lesson: security checks are gates too. Run them on every change.

TL;DR

  1. Injection = user text treated as code, in HTML, SQL or commands.
  2. XSS = a script injected into a web page.
  3. Escaping = turn <, >, & and quotes into safe text. Escape & first.
  4. Parameterized query = SQL with a placeholder like $1, and the value sent separately.
  5. Secret = a key or password. Keep it out of the code. Change it if it leaks.
  6. Slopsquatting = attackers publish packages under names AIs make up. Typosquatting = a name one letter from a popular one.
  7. Package check = exists, not a look-alike, widely used and not brand new.

Common mistakes

MistakeWrong ideaCorrect ideaWhat goes wrong
Pasting user text"Reviews are just text."Escape it, or let the framework do it.A script runs for every visitor.
Building SQL with text"I add quotes around the id."Use a parameterized query.' OR '1'='1 returns every order.
Deleting a leaked key"I removed the line, so it is safe."Change the key. Old versions keep it.Someone uses the key from history.
Installing what the AI says"The AI knows the package."Check it exists and is not a look-alike.Attacker code runs on your machine.
A noisy scanner"Flag anything that looks like a key."Allow env reads, placeholders and removals.People switch the scanner off.

Check Your Understanding

Exercises

What to Remember

  • Never paste user text into HTML, SQL or commands.
  • Escape HTML (& first) or let the framework do it. Use parameterized queries for SQL.
  • Keep secrets out of code. Change any key that leaks.
  • Check every package an AI suggests: it exists, it is not a look-alike, and it is widely used.
  • Run security checks as gates, in hooks and in CI.

Further Reading

Next: Flaky Tests and AI. You will find out why a test that is green on one run can be red on the next, and fix the cause instead of retrying.