Web Application Security Analysis: A Practical Guide to Testing SQL Injection and XSS

If you develop web applications or work in information security, understanding web security testing for SQLi and XSS is no longer a luxury—it is a fundamental necessity. SQL Injection and XSS are among the most common and dangerous vulnerabilities and are often the cause of user data leaks or admin panel compromises.

In this practical guide, we will walk step by step through:

• A simplified understanding of SQL Injection and XSS.
• How to test a web application against these attacks using only your browser.
• Automated vulnerability scanning tools and how to use them legally.
• Best protection practices for developers (with short code examples).

Before we begin, an important reminder: everything in this article is for educational purposes and legal security testing only. Do not test any website or system that you do not own or have written permission to test.

What Is SQL Injection?

SQL Injection is an attack in which an attacker injects malicious SQL commands into an input field (such as a login form or search box) so that they are executed by the database.

Classic example (PHP without protection):

$sql = "SELECT * FROM users WHERE username = '" . $_POST['user'] . "' AND pass = '" . $_POST['pass'] . "'";

If an attacker enters the following value in the username field:

' OR '1'='1

The query may become:

SELECT * FROM users WHERE username = '' OR '1'='1' AND pass = 'anything';

In this case, the query may return multiple rows and allow login without a valid password.

If you work with PHP, also see: How do I protect my application from SQL Injection attacks in PHP?

Signs of a SQL Injection Vulnerability

• SQL errors shown directly to the user (e.g., SQL syntax error, MySQL error).
• Ability to change the number or order of results by manipulating input values.
• Stable URLs with abnormal responses when parameters are modified.

What Is XSS? (Cross-Site Scripting)

XSS is a vulnerability that allows injecting JavaScript code into web pages so that it executes in users’ browsers. The danger is that an attacker can:

• Steal cookies or tokens (session hijacking).
• Perform actions on behalf of the user (CSRF combined with XSS).
• Display fake login prompts to steal passwords (in-site phishing).

Simple example: a comment field that is rendered without filtering. The attacker enters:

<script>alert('XSS');</script>

An alert box appears for every visitor to the page.

Types of XSS (Briefly)

• Reflected XSS: The payload is injected in the request and reflected immediately in the response.
• Stored XSS: The payload is stored in the database (e.g., comments) and served to all visitors.
• DOM-based XSS: Execution occurs in the browser via JavaScript without server-side response modification.

Legal and Ethical Rules Before Testing Web Security (SQLi & XSS)

• Test only:
  • Projects you own or your company owns.
  • Or projects where you have written authorization to test.
• Do not use these techniques on random websites or public services without permission.
• Keep logs of your testing activities for reporting.
• Remember that penetration testing is a regulated professional field. Learn more here: Penetration Testing: Methods, Tools, and Required Skills.

Practical Part: Web Application Security Analysis Against SQL Injection

1. Where to Look for Potential SQL Injection

• Login and registration forms.
• Search forms.
• URL parameters, for example:
  • product.php?id=5
  • /posts?category=1&page=2
• Any place where data is sent to the server (POST, GET, sometimes headers).

2. Simple Manual Tests (Browser or Burp Suite)

Start by injecting suspicious input and observe the application’s behavior. Common SQLi test payloads:

• '
• "
• ' OR '1'='1
• 1 OR 1=1
• 1 AND 1=2

What to watch for:

• Database error messages (e.g., You have an error in your SQL syntax).
• Changes in the number of returned results.
• Login behavior changes (accepting invalid credentials).

3. Practical Example: Testing an ID Parameter

Assume the following URL:

https://example.com/product.php?id=10

1. Change the value to 10':
   • If an SQL error appears, this is a strong indicator.
2. Try 10 OR 1=1:
   • If results increase or content changes unexpectedly, input filtering is weak.
3. Try 10 AND 1=2:
   • If results disappear, the value is likely used directly in a WHERE clause.

4. Using Automated Tools for SQL Injection

• sqlmap:
  • A powerful CLI tool for detecting and exploiting SQL Injection.
  • Can identify database types and extract table/column names.
  • Use only on systems you are authorized to test.
• OWASP ZAP:
  • A web security proxy with SQLi scanning capabilities.
  • Well-suited for DevSecOps integration.

5. How to Protect Against SQL Injection (Quick Tips)

• Use Prepared Statements / Parameterized Queries in all languages.
• Never build SQL queries by concatenating raw user input.
• Apply least-privilege permissions to database users.
• Hide SQL error messages in production.

Practical Part: Web Application Security Analysis Against XSS

1. Where to Look for Potential XSS

• Comment fields and forms whose input is displayed back to users.
• Search or filter fields whose values are reflected.
• URL parameters rendered directly in HTML.
• Any JavaScript that writes dynamic content (e.g., innerHTML).

2. Simple Manual XSS Tests

1. Test plain text:
   • Enter test123 and ensure it renders normally.
2. Test simple HTML:
   • <b>boldX</b>
3. Test JavaScript:
   • <script>alert('XSS');</script>

3. More Advanced XSS Payloads

• <img src=x onerror=alert('XSS')>
• <svg onload=alert(1)>
• " onmouseover="alert('XSS')

4. Automated XSS Scanning Tools

• OWASP ZAP
• Burp Suite (Community / Pro)

5. How to Protect Against XSS

• Output Encoding
• Input Validation
• HTTPOnly Cookies
• Content Security Policy (CSP)

Summary

By following these steps, you can build a structured methodology for testing web security against SQL Injection and XSS, combining manual and automated testing, and balancing offensive understanding with defensive implementation.

Improving your skills in this field requires continuous practice in legal environments and staying up to date with security best practices in the frameworks and languages you use.