SQL injection

SQL injection (SQLi) happens when a website builds a database query out of text that a visitor controls, such as a search box, a login form or a number in the web address, without keeping that text separate from the query itself. The attacker types a fragment of SQL instead of normal text, and the database runs it as part of the query.

It has been a fixture of the OWASP Top 10 list of serious web risks for years, under the heading "Injection". It is old, well understood and still found in real websites, because it only takes one careless line of code.

1. The attacker looks for an input that ends up in a database query: a URL parameter such as ?id=12, a search field, a login form.
2. They send a harmless-looking probe, often just a single quote, and watch for an error message or strange behaviour.
3. If the site reacts, they craft input that changes the logic of the query (for example making a condition always true) or appends a second query that reads other tables.
4. Automated tools then repeat this thousands of times to pull data out table by table, or in the worst cases to change or delete it.

• Requests in your logs with quote marks, SQL keywords (UNION, SELECT, DROP, SLEEP) or comment markers in the URL.
• Database error messages showing up in logs or, worse, on the page.
• Pages that suddenly respond slowly to certain requests (time-based probing).
• Unexpected new, changed or missing records, or admin accounts you did not create.
• Requests from tools that announce themselves, such as sqlmap, in the user agent.

• Theft of customer data: names, emails, orders and password hashes.
• Bypassing logins and gaining admin access.
• Changing or deleting data, which can take a business offline.
• Legal and trust consequences if personal data is exposed.

• Use parameterised queries (prepared statements) or a well-used ORM. Never build SQL by joining strings.
• Validate every input: expected type, length and allowed characters.
• Give the database account used by your website only the permissions it needs.
• Never show raw database errors to visitors; log them privately.
• Keep frameworks and database drivers updated.
• Add a web application firewall as an extra layer, not as the only layer.
• Take regular backups and test that you can restore them.

Not sure how your own site looks from outside? Run the free website security scanner.

Rakshak checks the address each visitor requests, meaning the path and the query string after decoding it, for patterns typical of SQL injection.

Examples of what it looks for: a quote followed by an always-true condition such as OR 1=1, UNION SELECT, a second statement such as ; DROP TABLE, time-delay functions such as SLEEP(), and references to system tables such as information_schema.

The patterns need real SQL context on purpose, so ordinary URLs that contain an apostrophe (a name like O'Brien) or a double dash are not treated as attacks.

• Every detection creates an alert in your Rakshak dashboard with the IP address, the request that triggered it, the severity and the time.
• If you have connected Telegram, Rakshak also sends you a message. You choose which severities you want to be told about.
• Repeated alerts of the same type from the same IP address are grouped for ten minutes, so you are not flooded with duplicates.
• SQL injection is a critical-severity detection, so Rakshak automatically adds the offending IP address to your blocklist. With the Rakshak server middleware installed, that visitor then sees an "Access denied" page instead of your website.
• Blocking needs the Rakshak server middleware on your website. The lightweight browser snippet can detect and alert, but a browser script cannot block a visitor.

A small shop shows products at /product?id=12. A scanning tool tries the page again with extra characters added to the id, hoping the database will react.

Rakshak sees the requested address, recognises the always-true condition, raises a critical SQL injection alert with the IP address and the request, and (with the middleware installed) blocks that IP so the probing stops.

The owner then checks that the page uses parameterised queries, so that the next, quieter attempt from another address is harmless too.

GET /product?id=12' OR '1'='1

Can SQL injection be detected from the web address alone?

Partly. Many automated attempts put their payload in the URL, and those can be recognised from the address. Attacks sent in a form body or in headers cannot be seen this way, which is why safe code matters more than detection.

Will Rakshak stop SQL injection on my website?

Rakshak detects SQL injection attempts that appear in the requested URL, alerts you, and can block the source IP address. It does not repair a vulnerable query. Fixing the code with parameterised queries is what removes the risk.

Is a single quote in a URL always an attack?

No. Names such as O'Brien and many normal links contain quotes. Rakshak looks for quotes combined with SQL context, so ordinary visitors are not flagged.

Do I still need parameterised queries if I use a firewall?

Yes. A firewall can only filter what it recognises. Parameterised queries remove the problem at its source and should always be the first defence.

What should I do if I think my database was accessed?

Change database and admin passwords, review recent logs and changed records, restore from a clean backup if data was altered, fix the vulnerable code, and check what notification duties apply to you if customer data was exposed.

How can I test my own site safely?

Test only sites you own or have written permission to test, preferably a staging copy. Use a code review and a reputable scanner against that copy rather than your live site.