SQL Injection SQLi

What SQL injection is

You run an online shop. A visitor types something odd into your search box, presses Enter, and the page shows them every customer's name, phone number and order history. Nobody stole a password. They typed the right words into the wrong place, and your website did the rest. This is SQL injection.

Most websites keep their information in a database: an organised store of tables, a bit like a set of spreadsheets. To read or change that information, the website speaks a language called SQL (Structured Query Language). Each request it sends is a query, for example "find the customer whose email is this one".

SQL injection happens when a website takes what a visitor types and pastes it straight into one of those queries. If the visitor types SQL instead of normal text, the database cannot tell the difference, so it follows the attacker's command as if the website had written it. People often shorten the name to SQLi.

How an SQL injection attack works

Think of a bank clerk who passes any note a customer hands over, word for word, to the vault staff. A normal note says "show me my balance". A tricky one says "show me my balance, and also open every safe". If the clerk never reads the note first, the vault staff obey.

On a website, the steps usually look like this:

1. The attacker finds a place that sends text to the database: a login form, a search box, a contact form, or the web address itself, such as a product page ending in "?id=25".
2. They type a small piece of SQL in place of normal text. A well-known example is typing ' OR '1'='1 into the password field of a login form.
3. The website joins that text to its own query without checking it. The query now asks something like "let this person in if the password is right, or if 1 equals 1".
4. Since 1 always equals 1, the database answers yes, and the attacker is logged in without knowing any password.

Some attacks are quieter. In a blind SQL injection, the page shows no data at all, so the attacker asks the database yes or no questions and watches how the page reacts, or how long it takes to load. It is slow work by hand, which is why attackers use free automated tools to do it for them.

What an attacker can do with it

Once the database follows their commands, the damage depends on what the website's database account is allowed to do. Often that is far more than the website needs. An attacker may be able to:

• read private data, such as customer names, addresses, emails, order history, medical records or stored passwords
• log in as another user, including an admin
• change data, such as prices, balances or the status of orders
• delete whole tables, or the full database
• in some setups, reach the server itself and plant harmful files on it

Why it matters to your business

SQL injection is one of the oldest web attacks, and it is still with us. OWASP, an open community that publishes the well-known OWASP Top 10 list of web application risks, has kept injection on that list for years. It is easy to try, and many sites still have one forgotten form that is open to it.

For a business owner, the real cost is rarely technical. It looks like a leaked customer list, a store selling at the wrong price, a booking system that loses a week of appointments, or a message you must send to clients telling them their data was exposed. In many countries, data protection laws such as GDPR also expect you to protect personal data and to report leaks.

Was every form on your site built with this in mind? Sites put together quickly from old plugins, or changed by many hands over the years, are more likely to hide a weak spot.

How to protect a website from SQL injection

The main fix is well known, and it works. Most of the protection lives in how the website is built, so these are good questions to ask your developers or your provider.

• Prepared statements. Also called parameterised queries. The website sends the query and the visitor's text separately, so the database always treats the text as plain data and never as a command. This is the main defence. Modern frameworks such as Laravel do this by default when developers use their built-in database tools.
• Input checks. A phone number field should accept digits only, and a date field should accept dates only. Turning away strange input early closes many doors.
• Least privilege. The account the website uses to reach the database should have only the rights it needs. A public search page has no reason to delete tables.
• Quiet error messages. A detailed database error on screen gives an attacker a map. Show visitors a short, simple message and keep the details in private logs.
• Updates. Keep the platform, plugins and libraries up to date, because old versions often have known holes.
• A web application firewall. This is a filter in front of the site that blocks many known attack patterns before they reach your code. It helps, but it does not repair unsafe code.
• Regular testing. Penetration testing (a safe, planned attack by experts) and vulnerability scanning find the weak spots before an attacker does.

Here is how everyday habits compare:

Mistakes people make

• Trusting checks in the browser. Checks that run on the visitor's own device are easy to skip, so the server must check everything again.
• Thinking a small site is safe. Automated tools scan huge numbers of sites without caring how big they are.
• Fixing one form and forgetting the rest. The search box, the filters, the web address and the API behind a mobile app all need the same care.
• Storing passwords as plain text. If data leaks, passwords stored with strong hashing (turned into a scrambled code that cannot be read back) are much harder to misuse.
• Relying on a firewall alone. A filter buys time. The unsafe query behind it still has to be fixed.

How we can help

At Linkysoft, testing for SQL injection is part of our cybersecurity services. We run safe, simulated attacks on your website, app and API, review the code, and give you a plain-language list of what we found and how to fix it. After the fixes, we test again. This works for sites built by other teams too, and the free security check is an easy first step.

Planning a new system? Our web applications and management systems are secure by design, with OWASP Top 10 hardening and penetration testing before launch.