Free web security training from @PortSwigger
- Tweets 1,907
- Following 36
- Followers 146,675
- Likes 324
Everyone who wants to learn:
1️⃣ XSS
↪️ SSRF
🤔 OWASP
🪟 DOM XSS
🔐 Auth bypass
💉 SQL injection
📁 File upload vulns
📦 GraphQL Hacking
🧰 Burp Suite Mastery
🧠 Business Logic Flaws
💔 Broken Access Control
🏴☠️ Real Exploit Techniques
💥 Much, much, much, more
I hope you found this account.
16
64
934
41,431
Web Security Academy retweeted
After months of grinding
my first bounty of the year just landed. 🎉
From learning labs on @PortSwigger
to finding a CVE-level vulnerability
on a real target.
Responsible disclosure.
Bounty awarded. ✅
#bugbounty #WebAppPentesting
#infosec #CVE #Thecybrarians
37
13
208
7,340
Web Security Academy retweeted
Progress on PortSwigger so far
Added cloud security to my toolkit, if you're into cloud, let's connect 🫱🏻🫲🏽
@ireteeh @TemitopeSobulo @_DeejustDee @cyberjeremiah @segoslavia
11
14
107
3,790
Template probing indicates server-side expression evaluation?
Next, confirm where the input lands: plaintext template context or code context. Then identify the template engine, because syntax and results can differ between engines.
The change in response is the next lead, though impact varies from application to application.
Test the workflow in the free SSTI labs 👇
portswigger.net/web-security…
2
29
259
9,230
Web Security Academy retweeted
+80% PortSwigger Web Security Academy labs solved. 🥷🤍
One of the goals I’ve been working toward for a long time, and honestly, seeing the progress feels great.
The biggest benefit for me hasn’t just been solving the labs.
Still a long way to go, but I’m enjoying the process
1
1
9
1,284
Web Security Academy retweeted
100 Days of PortSwigger 🔐
3 months in, 195 labs solved across nearly every topic on the Web Security Academy.
But labs were only half of it - I've been applying it all on live, authorized targets and already reported several high & critical findings.
Almost everything came down to two things:
→ Business logic flaws - the bugs no scanner catches
→ Broken access control - still one of the most impactful issues out there
The real edge? Burp Suite, every single day. Doing it manually builds an intuition automation never will - which is exactly what matters when the scanner comes back clean.
Finishing stage now. Remaining labs + the exam soon. 🚀
#BSCP #BurpSuite #WebSecurity #PenTesting
2
1
15
1,425
Web Security Academy retweeted
XSS from a response header 🤯
Firefox will load an XSLT stylesheet from a data: URL in a Link header. Combined with a harmless XML body and you get JS running in the page origin.
Plus Safari importing GIFs as SVG and more sanitizer bypasses
2
26
110
6,185
Seeing isAdmin in the API should instantly make your hacker-senses tingle.
Seeing it doesn't necessarily mean it's writable, but it's worth investigating.
Compare the object returned by GET with fields accepted by PATCH. An invalid-value test can reveal whether a hidden field is actually bound to the internal object.
See the Academy API-testing lesson 👇
portswigger.net/web-security…
6
29
293
10,904
Would the origin check accept app.example.attacker.test?
Substring, prefix, and suffix checks can accept an attacker-controlled origin that merely contains the expected domain.
Before event.data reaches a privileged action or DOM sink, validate event.origin against an exact, allowlisted origin.
Review the Academy lesson in your authorized app 👇
portswigger.net/web-security…
ALT A person wearing a hoodie sits at a table using a laptop displaying a fox logo, with a small backpack nearby. A diagram reads: "postMessage() CHECK" with steps including "received the message," "verify event.origin exactly," and "only then use event.data." Risky and safe practices are compared regarding origin validation. A box with a cat face and "User is admin!" text is on the floor. The image has Web Security Academy branding.
7
52
4,323
It's sometimes possible to take someone's private web app dashboard and trick it into being publicly cached.
The cache sees a static-looking request and stores the response, even though it shouldn't, and then you can view it as an attacker!
Learn more and try it yourself 👇
portswigger.net/web-security…
5
22
173
6,703
Before you trust the signature, open the JWT header and check 👇
🟧 alg tells the verifier which signing algorithm to try.
🟧 kid can select a verification key.
🟧 jku can tell a verifier where to fetch a key set.
Those fields are supplied by the token holder. The application should whitelist permitted algorithms and trusted key sources, then validate issuer, audience, and expiry.
Inspect JWTs in the free labs 👇
portswigger.net/web-security…
ALT A checklist titled "JWT verification checklist" on a dark blue background includes five items: "Algorithm is allowed," "Key source is trusted," "Issuer matches," "Audience matches," and "Token is still valid." Each item has a checkmark next to it. The bottom left shows the logo of Web Security Academy.
1
5
61
4,061
Pro tip for SSRF!
Blocking 127.0.0.1 does not necessarily account for every representation a parser may resolve as loopback. Depending on the parser, that can include case variations of localhost or shorthand forms such as 127.1.
Compare validation, normalization, DNS resolution, and the final request.
Explore the Academy SSRF labs 👇
portswigger.net/web-security…
2
45
409
15,278
What happens if this WebSocket handshake comes from another site?
Origin: https://evil.example
Send the handshake to Burp Repeater, change the Origin header, and reconnect.
If the server returns 101 Switching Protocols, inspect how the session is protected.
When the handshake relies only on a session cookie, contains no unpredictable token, and the victim’s browser sends the cookie cross-site, an attacker-controlled page could open the WebSocket as the victim.
The page then sends messages and reads responses in the victim’s session.
Follow the handshake in the free lab 👇
portswigger.net/web-security…
4
44
5,209
Can you change the response without changing the cache key?
In Repeater, add 👇
X-Forwarded-Host: cache-test.example
Then compare the response.
If the header changes the response but the cache does not include it in its key, it is an unkeyed input.
When that altered response is cached, later requests with the same cache key can receive it too.
Find the ignored input in the free labs 👇
portswigger.net/web-security…
1
24
223
11,025
Web Security Academy retweeted
You're in control with Burp AT.
The latest update makes sure Burp AT works your way:
📖 Custom skills for your methodology
🎯 /goal to keep it working until it gets there
💡 Requests, issues and docs as context
🚧 Reject, redirect or approve tool calls
#BurpAT
2
5
32
5,127
Web Security Academy retweeted
“Burp AT integrates seamlessly with Burp’s existing tooling and functionality, instead of being just another chat interface to an LLM.”
Burp AT vs Juice Shop, Safe Mode on, no hints: 3 unintended RCEs and a critical handlebars CVE (CVSS 9.2).
@ElliottSaysWhat, web app pentester at Leidos, shares what to feed it, how to steer it and what it cost.
brandon-t-elliott.github.io/…
2
9
47
6,163
Your password reset link:
https://attacker[.]com/reset?token=0a1b2c...
Why is the domain an attacker domain?!
That can happen when an application uses the request’s Host header to build the reset URL. This was actually a vulnerability in older versions of WordPress!
The email is genuine and the token is valid, but the domain is controlled by an attacker. If the victim opens the link, the token reaches the attacker’s server and can be used against the real reset endpoint.
Try exploiting this vulnerability yourself in our labs 👇
portswigger.net/web-security…
4
72
5,732
In Burp Repeater, try changing the file’s Content-Type to image/jpeg.
If a previously blocked upload is now accepted, the server may be trusting the multipart header instead of checking the file itself.
That header is supplied by the client. Validation also needs to consider the filename, extension, actual contents, storage location, and whether the server can execute the uploaded file.
Try it in the file upload labs 👇
portswigger.net/web-security…
2
31
358
12,616
Web Security Academy retweeted
How do you test how powerful an AI testing tool is?
@0xTib3rius built his own target: a bespoke vulnerable app, source code never published, with three known, tricky paths to RCE. Then he tried Burp AT.
Burp AT found a fourth within minutes.
#BurpAT
1
6
30
5,852
Sometimes applications are vulnerable to CSRF even when they use CSRF tokens!
This happens when the CSRF token isn't tied to the active session.
If an application accepts any token from a global pool, an attacker can create one from their own account and craft a CSRF payload to force a victim to perform requests on their account, using the attacker's CSRF token.
When testing for CSRF, you need to ask 2 questions:
- Does the application use CSRF tokens?
- Are the CSRF tokens tied to sessions?
Try it out in the free labs 👇
portswigger.net/web-security…
3
29
5,360