Detect injection attacks
Paste admin' OR 1=1 -- and the check flags it as suspicious with an SQL pattern, the classic trick for slipping past a login form. It also spots script tags, shell commands and path tricks. Free in your browser.
- Free
- Runs in your browser
- No sign-up
- Your data stays on your device
Run — free
Worked example
- Text
- admin' OR 1=1 --
- Detected patterns
- sql
A single unescaped quote in a login form can end with your users table on a paste site; a single stray backtick in a filename field can end with a shell command you never wrote.
Why ordinary text can turn into an attack
An injection attack hides instructions inside data. Any place where your site takes a string from outside and later treats part of it as a query, a page or a command is a place where someone can smuggle in their own orders. A single unescaped quote in a login form can expose a whole table of users; a stray backtick in a file name can run a command nobody wrote. This check reads the string itself and looks for the telltale shapes of database injection, cross-site scripting, shell commands and path traversal, then tells you whether it looks suspicious and which kind of pattern it found.
Where it helps, and what it does not replace
It is most useful in front of things you cannot rewrite quickly: an old customer form, a plugin from someone else, a feature that was rushed into production. Put the check on submission and you buy time without a full rebuild. It is a second line of defence, not the fix itself. Safe queries and proper escaping in your own code are still what stop injection for good, and a clean result here does not prove a page is secure.
The problem, stated plainly
Injection attacks have topped vulnerability rankings for over two decades for a mundane reason: any place your application takes a string from the outside world and later treats part of it as code, structure or a command is a place an attacker can smuggle instructions inside data. Parameterized queries and output escaping remain the real fix at the code level, but real systems are large, inherited, and full of edge cases where a legacy form, a third-party plugin or a rushed feature bypasses the safe path.
What you can do with it
Legacy form hardening
Wrap an old customer-facing form you can't rewrite this quarter with an injection check on submission, buying time without a full refactor.
Third-party plugin sandboxing
Route inputs from a marketplace plugin you don't control through the check before they reach your core database layer.
FAQ
Is there a free plan?
The tool above runs free in your browser. No subscription, no tokens, and a failed task is never charged.
Can this replace parameterized queries?
No. It's a detection and monitoring layer, not a substitute for parameterized queries, prepared statements and output escaping in your own code.
Will it flag legitimate text that happens to contain SQL-like words?
The check looks for structural and syntactic patterns, not just keywords, to reduce false positives on legitimate text that merely mentions terms like SELECT or DROP.
Is submitted input data retained?
No, all submitted data is deleted after the retention window and is never used for training.
How can I tell if a form input is an SQL injection attempt?
Paste the text into the check. A string such as admin' OR 1=1 -- comes back marked as suspicious and labelled as an SQL pattern, which tells you it is trying to rewrite your query rather than fill in a username.
Related tools
For developers — API access
Everything on this page is available programmatically. This section is for teams who want to wire it into their own systems; everyone else can just use the tool above.
API endpoint
Prefer to automate it? One authenticated POST creates the task; the result comes back by webhook or a signed link. The same capability also runs here on the web, by email and from Telegram — and soon from our app too.
Call it from your stack
curl -X POST https://api.kit.forhosting.com/verify/injection \
-H "Authorization: Bearer $KIT_KEY" \
-H "Content-Type: application/json" \
-d '{"text":"1'\'' OR '\''1'\''='\''1"}'const res = await fetch("https://api.kit.forhosting.com/verify/injection", {
method: "POST",
headers: {
"Authorization": `Bearer ${process.env.KIT_KEY}`,
"Content-Type": "application/json"
},
body: JSON.stringify({
"text": "1' OR '1'='1"
})
});
const { task_id } = await res.json();import os, requests
res = requests.post(
"https://api.kit.forhosting.com/verify/injection",
headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
json={
"text": "1' OR '1'='1"
},
)
task_id = res.json()["task_id"]<?php
$res = file_get_contents("https://api.kit.forhosting.com/verify/injection", false, stream_context_create([
"http" => [
"method" => "POST",
"header" => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
"content" => '{"text":"1\' OR \'1\'=\'1"}',
],
]));
$task = json_decode($res, true);body := bytes.NewBufferString(`{"text":"1' OR '1'='1"}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/verify/injection", body)
req.Header.Set("Authorization", "Bearer "+os.Getenv("KIT_KEY"))
req.Header.Set("Content-Type", "application/json")
res, _ := http.DefaultClient.Do(req)Example request
{
"text": "1' OR '1'='1"
}Example response
{
"task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
"type": "verify.injection",
"status": "queued",
"_links": {
"result": "/tasks/tsk_…/result"
}
}The API is asynchronous: the call returns a task_id immediately and the result arrives by webhook. Polling is capped at 1 req/s per task.
Pricing
Published price — no tokens, no invented credits. A failed task is never charged.
Errors
| HTTP | Code | Meaning |
|---|---|---|
401 | unauthorized | Missing or invalid API key. |
402 | insufficient_balance | Your balance doesn't cover the task price. |
404 | unknown_type | That task type doesn't exist. |
429 | rate_limited | Too many requests. Use the webhook instead of polling. |
Technical notes
The injection detection API inspects any input string for the syntactic fingerprints of SQL injection, cross-site scripting and command injection, and hands back a verdict before that string ever touches a query, a page render or a shell call.
The problem, stated plainly
This endpoint is a second line of defense that catches the string itself before it does damage, regardless of what happens to it downstream.
Who reaches for this endpoint
Teams running legacy forms they can't fully refactor on a deadline, API gateways that want a generic input-sanity layer in front of many downstream services with different data handling, and WAF-adjacent tooling that needs a scoring signal rather than a hard block all fit naturally here. It's equally useful as a defense-in-depth layer even on well-written code, since a second independent check catching a mistake before production is far cheaper than the incident that follows if it doesn't.
Where it fits in a request pipeline
Because the check is asynchronous, most integrations call it at the edge, in a validation microservice, or as an async pre-write gate rather than inline on every keystroke; a task_id comes back immediately and the verdict follows by signed webhook, or through a signed link valid 24 hours for pipelines that prefer to poll rather than receive callbacks. At $0.002 per request with failed checks never billed and three automatic retries before a clear error, it's priced to run on every write path, not just a sampled subset.
What it is not a substitute for
Detecting an injection pattern in a string is not the same as your application being immune to injection; parameterized queries, prepared statements and proper output encoding remain the actual fix. Treat this endpoint as an early-warning and monitoring layer that catches obvious and moderately obfuscated attempts fast and cheaply, not as a replacement for secure coding practices in the code that ultimately executes the query.
Integration use cases
API gateway pre-checks
Screen incoming payloads at the gateway before they reach any of several downstream services, standardizing detection instead of duplicating it per service.
Security monitoring and alerting
Log every flagged injection attempt with its category to feed a dashboard that shows attack patterns targeting specific endpoints over time.
Technical questions
Does the injection detection API work for both SQLi and XSS?
Yes, a single call checks for SQL injection, cross-site scripting and command-injection patterns and returns which category, if any, was detected.
What does a check cost?
$0.002 per request, charged only when the task completes successfully; failed checks are never billed and are retried automatically up to three times.
How do I get the result?
By signed webhook, recommended for automated pipelines, or via a signed link valid 24 hours if you prefer to poll for the result.
Can I check many inputs in bulk?
Yes, call the endpoint once per string; each call is an independent async task with its own task_id, which suits high-throughput validation pipelines.