Detect injection attacks
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. 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.
Run — free
Runs in your browser. Free, unlimited — your data never leaves this page.
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. This endpoint is a second line of defense that catches the string itself before it does damage, regardless of what happens to it downstream.
What the check actually looks for
Call POST /verify/injection with the input string and the task scans for SQL injection markers such as tautologies, comment sequences and stacked queries, cross-site scripting patterns including script tags, event-handler attributes and encoded payload variants, and command-injection indicators like shell metacharacters and chained command separators. It returns which category triggered and why, so your logging and alerting can distinguish a script kiddie's obvious probe from a more deliberate, obfuscated attempt worth escalating.
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.
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.
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.
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
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.
Is there a free plan?
The tool above runs free in your browser. The API is paid — each call draws from your prepaid ForHosting KIT balance: top up from $10.00 (it never expires), pay each request's published price, and a call with no balance returns HTTP 402. No subscription, no tokens, and a failed task is never charged.
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.
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.
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.
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.
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.
Is submitted input data retained?
No, all submitted data is deleted after the retention window and is never used for training.
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, and soon from our app, email and Telegram.
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 '{"items":["valor-1","valor-2"]}'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({
"items": [
"valor-1",
"valor-2"
]
})
});
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={
"items": [
"valor-1",
"valor-2"
]
},
)
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" => '{"items":["valor-1","valor-2"]}',
],
]));
$task = json_decode($res, true);body := bytes.NewBufferString(`{"items":["valor-1","valor-2"]}`)
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
{
"items": [
"valor-1",
"valor-2"
]
}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. |