31 bite-sized tips, techniques, and bug bounty resources to kick off 2026!

What you will learn

• Practical, bite-sized bug bounty tips and techniques you can apply immediately, whether you’re just starting or sharpening your skills.

• Proven approaches for finding, prioritizing, and validating vulnerabilities more efficiently in real-world programs.

• An eye on what to look out for to stay consistent and motivated in 2026.

In the lead-up to the new year, we released a bug bounty tip every day during the month of December. This article compiles each of these tips, provides links to social posts and snippets, and expands on some of the concepts explored.

Let’s kick things off with an old classic… XSS, but with a twist!

Tip 1: Hunting for blind XSS with match and replace rules

Link to social post here.

XSS stands for Cross-Site Scripting. ‘Cross-Site Scripting (XSS) attacks are a type of injection, in which malicious scripts are injected into otherwise benign and trusted websites. XSS attacks occur when an attacker uses a web application to send malicious code, generally in the form of a browser-side script, to a different end-user.’ -OWASP

Automatically inject blind XSS payloads while browsing your targets, helping you discover vulnerabilities more efficiently. To find blind XSS vulnerabilities while browsing, set up this match and replace rule in your proxy interceptor to auto send your blind XSS payload in each request. The delayed execution, invisible injection point, and the requirement of a dedicated server that handles incoming invocations make it difficult to find and exploit blind XSS vulnerabilities. However, these XSS types are more critical by nature, which makes them worth testing for.

This article serves as a comprehensive guide to identifying and exploiting blind XSS vulnerabilities.

Tip 1: Hunting for blind XSS with match and replace rules

Tip 2: Fuzzing for virtual hosts with FFUF

Link to social post here.

FFUF, which stands for ‘Fuzz Faster U Fool’ is a fast web fuzzing tool created in Go.

‘To understand the program, we first need to understand what fuzzing is. Fuzzing is the automated process of sending random data to an application to find misconfigurations, unexpected behavior, or hidden parameters. FFUF is the fuzzer of choice for lots of researchers these days.’ - FFuF (Fuzz Faster u Fool)

An easy way to find more bugs is to discover assets that have never been tested before. Vhost fuzzing discovers virtual hosts that are not publicly listed in DNS by testing different Host header values, and it is one of the most underutilized methods for identifying assets.

Quick guide
1. Install and use a tool like FFUF

2. ffuf -u $TARGET -H "Host: FUZZ.$TARGET" -w /path/to/wordlist

3. Now filter for live hosts in the results

Tip 2: Fuzzing for virtual hosts with FFUF

Tip 3: Find related assets via favicon hash enumeration

Link to social post here.  

Find undiscovered assets by enumerating related assets via the favicon hash.

Favicons are the small icons that appear on the web browser's tab next to your page title. These images that appear in your tab are much more than just icons. Sometimes, they can help find related assets that may be vulnerable and are often used as favicons on new hosts as well.

Some hosts are set up for development or administrative purposes only and have no (sub)domain pointing to them. They do have a few similarities that can help us track these down, such as the favicon icon.

Take the hash and use tools like Shodan and Censys to list all hosts with a matching favicon hash.

‘In some cases, especially when your target is a smaller company, it may not have a reserved IP space, or the company regularly deploys hosts in various regions across the world using third-party cloud services like AWS or Azure. We can, in that specific context, still identify hosts that belong to your target using the favicon hashes.’ - 7 Overlooked recon techniques to find more vulnerabilities

Here is a simple one-liner to calculate a Shodan favicon hash with Python3.

Tip 3: Find related assets via favicon hash enumeration

Tip 4: Hosts with certificate issues

Link to social post here.
Developers sometimes forget to take down hosts if they are no longer relevant. By monitoring for SSL/TLS certificate errors, we can identify forgotten hosts to expand our initial attack surface. These forgotten servers with expired certificates are ideal targets, as they do not receive the same security attention as the primary application would.

The following queries for both Shodan and Censys can help you discover these neglected assets.

Tip 4: Hosts with certificate issues

Tip 5: Copyright notices

Link to social post here.
Most developers include copyright notices in their code without realizing how these can be leveraged for reconnaissance. By searching for unique copyright labels, you can find related hosts that other bug bounty hunters haven't tested yet.

How does it work?

Identify assets owned by the same organization that might not be documented in their scope simply by searching for copyright notices. Here is a practical example of how to leverage this method to expand your attack surface with Shodan and Censys.

Tip 5: Copyright notices

Tip 6: Brute forcing hosts with redirects

Link to social post here.

If you find a subdomain that immediately redirects you to another location, don’t skip it. Just because a host redirects at the root doesn't mean there's nothing there. Even though the index redirects, other paths might be exposed and unprotected. Hidden directories and files can still be accessible and often contain sensitive data or could even lead to vulnerabilities.

‘A brute force attack can manifest itself in many different ways, but primarily consists of an attacker configuring predetermined values, making requests to a server using those values, and then analyzing the response’ – OWASP

See the example below of how you can brute-force targets while filtering out the noise.

Tip 6: Brute forcing hosts with redirects

Tip 7: Fuzzing with multiple HTTP methods

Link to social post here.
Many application routes and API endpoints are configured to respond exclusively to specific HTTP methods. That’s why you should always perform content discovery with multiple HTTP methods.

Brute forcing (or fuzzing) is an integral part of discovering unreferenced and hidden hosts, API endpoints, app routes, or input parameters. Many endpoints and API routes are configured to respond only to specific HTTP methods such as POST, PUT, or DELETE. By fuzzing with multiple methods, discover accessible paths that won't show up in standard GET-only fuzzing.

Have a look at the following example using FFUF.

Tip 7: Fuzzing with multiple HTTP methods

Tip 8: Finding secrets in internal web browser extensions

Link to social post here.

Organizations frequently develop custom web extensions for internal workflows, but these can sometimes be made publicly accessible. By enumerating these extensions, discover hard-coded secrets, API keys, internal paths, and even security vulnerabilities. A simple Google dork can reveal these internal tools that were never meant to be public.

How does it work?

Organizations often develop web extensions for internal tasks, but sometimes make them publicly accessible by accident. Enumerating these can help you find hard-coded secrets and vulnerabilities.

Tip 8: Finding secrets in internal web browser extensions

Tip 9: Open registrations on third-party services

Link to social post here.

Many organizations deploy platforms like Jira, Jenkins, or ServiceNow, but forget to disable public sign-ups. If you encounter a target that uses Atlassian Jira, Jenkins, or ServiceNow, always check for open registrations. Authentication sessions almost always have elevated privileges and can help you discover more functionality to test.

Here are some common registration paths to check.

Tip 9: Open registrations on third-party services

Tip 10: WAF protections by finding origin IPs

Link to social post here.

Many targets hide behind Cloudflare or other Web Application Firewalls (WAFs), making testing difficult by blocking the payload requests. However, when direct IP access is enabled, it is possible to bypass these protections by reaching the origin IP. Using historical DNS records from certificate transparency logs, can find the actual server IP before protection was added. Once you have the origin IP, you can test directly against the server while completely bypassing WAF rules. This technique has uncovered vulnerabilities that were previously hidden.

Here is an example:

Tip 10: WAF protections by finding origin IPs

Tip 11: Fingerprint technologies via company job postings

View the social post here.

As companies publish new job postings, we can often find references to technologies, services, and other third-party tools that are not publicly documented. This method can help with generating custom wordlists, crafting injection payloads, discovering third-party services, and understanding the tech stack you are testing.

Here is an example.

Tip 11: Fingerprint technologies via company job postings

Tip 12: Find cloud storage buckets with Google

View the social post here.

Cloud storage buckets are goldmines for sensitive data as they can store customer data, invoices containing PII, backups and archives, and much more. Companies often use predictable naming conventions, making these buckets discoverable through simple searches.

To hunt for exposed cloud storage buckets using Google, see the compiled search queries for the most popular blob storage services below. And read more on ‘Hacking misconfigured AWS S3 buckets: A complete guide’ for eight top tips.

Tip 12: Find cloud storage buckets with Google

Tip 13: R2 dev on Cloudflare R2 buckets

View the social post here.

Cloudflare R2 buckets and the feature that's often misconfigured is R2 dev. R2 dev is a feature that allows developers to make bucket contents publicly accessible for testing purposes. If this feature is left enabled in production, it may expose sensitive files, credentials, backups, and other critical data.

Read ‘Hacking misconfigured Cloudflare R2 buckets: A complete guide’ and check to see if it is enabled. If so, this can expose sensitive files, backups, configuration data, and even PII. Look at this query.

Tip 13: R2 dev on Cloudflare R2 buckets

Tip 14: DOM-based XSS

View the social post here.

Document Object Model (DOM)-based XSS vulnerabilities are often hard to spot due to their limited visibility. They're also harder to test for at scale, making them more prone to being missed by researchers. Luckily, there's a simple way to test for DOM XSS using your browser's developer console. By setting event breakpoints on DOM sinks, you can intercept and analyze how your input flows through the application.

1.     Open your sources tab.

2.     Locate any DOM sinks.

3.     Add event breakpoints.

4.     Analyze intercepted events and see if your unsensitized input is passed to a DOM sink.

Tip 14: DOM-based XSS

Tip 15: Content Security Policy (CSP) bypasses

View the social post here.

Many applications implement strict Content Security Policies to block XSS, but if trusted domains like Google, YouTube, or GitHub, are whitelisted, these restrictions can often be bypassed using JSONP endpoints. JSONP allows you to specify a callback function in the URL, which means you can execute arbitrary JavaScript even when CSP is enforced. This technique has saved countless XSS findings from being blocked.

Learn more in this blog on ‘Bypassing Content Security Policy (CSP).’

Tip 15: Content Security Policy (CSP) bypasses

Tip 16: Testing for blind XSS vulnerabilities

View the social post here.

Blind XSS is a web application vulnerability that occurs when a payload executes in a different context, such as an admin panel, analytics page, or any other type of internal dashboard. These are some of the most impactful findings because they often affect privileged users.
Compiled below are payloads for various scenarios, including basic script injection, image tags, jQuery exploitation, CSP bypasses, and even AngularJS template injection.

View the collection of blind XSS payloads to catch those hidden XSS vulnerabilities. And remember to host these on your own server to catch social engineering callback scams.

Tip 16: Testing for blind XSS vulnerabilities

Tip 17: SSRF and how to discover internal open ports

View the social post here.

SSRF stands for Server-Side Request Forgery. It is a web vulnerability where threat actors trick servers into making malicious network requests. A simple FFUF command lets you scan internal ports by fuzzing the port number in your SSRF payload, helping you discover internal services like databases, admin panels, or APIs. The benefit here is that port scanning through SSRF can reveal critical internal infrastructure that's not exposed to the internet. This is how you can turn a medium-severity SSRF into a high or critical finding.

Tip 17: SSRF and how to discover internal open ports

Tip 18: Generating malicious PDFs for file upload vulnerabilities

View the social post here.

Generate malicious PDFs to test file upload vulnerabilities. When testing file uploads, many bug hunters focus on web shells and images, but can forget about PDF processing vulnerabilities. PDFs can trigger server-side rendering issues, Server-Side Request Forgery (SSRF), Cross-Site-Scripting (XSS), and even Remote Code Execution (RCE).

This tool generates various payloads that test for common PDF vulnerabilities. Simply clone the repo, generate your payloads with your callback URL, and upload them to see if the server processes PDFs unsafely.

Tip 18: Generating malicious PDFs for file upload vulnerabilities

Tip 19: Bypass file upload restrictions with Magic Bytes

View the social post here.

Magic Bytes are unique sequences, also referred to as magic numbers or file signatures, that are placed at the beginning of a file to show its format. A researcher can bypass magic byte validation to upload executable files.

Some developers only validate the first few bytes of uploaded files (magic bytes) without checking the entire file structure. By prepending valid magic bytes such as PNG headers to the malicious payload, these weak validations can be tricked into accepting files that will execute on the server.

This technique works particularly well when combined with other bypass methods like double extensions or content-type manipulation. It's a classic file upload bypass that still catches many applications off guard.

Read more on exploiting file uploads here.

Tip 19: Bypass file upload restrictions with Magic Bytes View the social post here. Magic Bytes are unique sequences, also referred to as magic numbers or file signatures, that are placed at the beginning of a file to show its format. A researcher can bypass magic byte validation to upload executable files. Some developers only validate the first few bytes of uploaded files (magic bytes) without checking the entire file structure. By prepending valid magic bytes such as PNG headers to the malicious payload, these weak validations can be tricked into accepting files that will execute on the server. This technique works particularly well when combined with other bypass methods like double extensions or content-type manipulation. It's a classic file upload bypass that still catches many applications off guard. Read more on exploiting file uploads here.

Tip 20: Bypassing paywalls via currency confusion attack

View the social post here.

Users should be unable to tamper with price or currency values on e-commerce applications. But it is possible to bypass the paywalls via a currency confusion attack. By changing the currency from USD to a weaker currency such as INR or JPY (Indian Rupee or Japanese Yen), you may be able to purchase items for a fraction of the actual cost.

‘Exchange rate functions are used by e-commerce companies to cater to global audiences. They are a necessary part of business. But what makes organizations vulnerable to currency confusion is, again, a lack of validation. When there is a lack of validation, a threat actor takes advantage of the exchange rate function, with the goal of manipulating the transaction to pay a small amount in one currency while being charged for a much larger value item priced in a different currency.’ Read this blog on ‘Price distortion identification’

If you do come across a target where you have control over the currency parameter, try manipulating it to decrease the actual order value.

Tip 20: Bypassing paywalls via currency confusion attack

Tip 21: Bypassing paywalls via race condition attacks

View the social post here.
One of the most used marketing strategies in e-commerce platforms is the implementation of a discount system. However, when developers fail to properly handle concurrent requests when validating coupon codes, it can allow us to apply the same single-use coupon multiple times before the system marks it as used.

‘When a coupon is not set up correctly by the provider, it leaves the user and the company vulnerable. For instance, when coupons are implemented insecurely, it can potentially allow malicious actors to redeem expired codes, apply the same code multiple times, or even generate new codes by abusing incorrect application logic.’ – Discount disasters in coupon validation systems

The easiest way to test for this is to use Burp's send in parallel feature.

Tip 21: Bypassing paywalls via race condition attacks

Tip 22: Bypassing paywalls with test cards

View the social post here.

Sometimes, developers forget to disable test cards in production environments, which can occur when testing in a live environment. With the help of these test cards, we can test faulty transaction handling and possibly place orders without incurring any charges!  

Save this list of test cards for your e-commerce testing.

Tip 22: Bypassing paywalls with test cards

Tip 23: Exploiting WordPress targets

View the social post here.

Over half a billion websites run on WordPress, which, with over 70,000 plugins, is a significant attack surface.

There is a systematic approach to exploiting WordPress targets; the key is to enumerate active plugins and search for known vulnerable versions in vulnerability databases such as WPScan. This methodology has led to numerous critical bugs, including RCE, SQLi, and XSS.

1.         Enumerate active plugins in the source code and check for scripts/style sheets prefixed with WordPress content plugins.

2.         Brute-force plugins using a wordlist to enumerate any unused plugins

3.         Search for vulnerable versions.

For more information, read this blog on ‘How to hack WordPress plugins’.

Tip 23: Exploiting WordPress targets

Tip 24: Testing for ‘none’ algorithm JWT attack

View the social post here.

Critical JWT (JSON Web Tokens) misconfigurations are surprisingly common in older applications.

When looking at HTTP requests, you’ve most likely seen a series of numbers and letters like this.

Tip 24: Testing for ‘none’ algorithm JWT attack

This is a JWT token. Every token consists of three parts delimited by a ‘.’, where every part is base64 encoded data. The first section is the header, which contains claims about the algorithm being used for signing or encrypting, and much more.

Some JWT implementations accept the 'none' algorithm, which means no signature verification is performed. By decoding the JWT and changing the 'alg' header to 'none', you can forge valid tokens.

This works when applications fail to properly validate the algorithm used to sign tokens. It's a quick win that can lead to complete authentication bypass and privilege escalation.

Read this blog on ‘JWT_Tool – The JSON Web Token Toolkit’ and follow these steps:

1.         Base64 decode the JWT header and payload

2.         Set the ‘alg’ header properly to ‘none.’

3.         Tamper with the claims

4.         Remove the signature entirely (leave the trailing dot)

Tip 25: Testing for JWT key ID injection attack

View the social post here.

JWT vulnerabilities extend beyond the 'none' algorithm. Tip 24 showed how to bypass JWT authentication by exploiting the 'none' algorithm. But there is another JWT attack known as key ID (kid) injection. This misconfiguration is still present in older applications and can lead to complete authentication bypass and privilege escalation.

This is where the 'kid' parameter instructs the application which key to use for signature verification. If this parameter isn't properly validated, attackers can manipulate it to point to predictable files or locations, allowing them to forge valid tokens with known keys.

It's another reminder that trusting user-controlled input, even in JWT headers, is dangerous.

1.         Base64 decode the JWT header and payload

2.         Set the ‘kid’ header property to ‘../../../dev/null’ (adjust as needed)

3.         Tamper with the claims.

4.         Sign your forged JWT with the exact same key file (e.g. /dev)

Tip 25: Testing for JWT key ID injection attack

Tip 26: XXE via UTF-7 charset

View the social post here.

External Entity (XXE) attacks protection can be bypassed by injecting your payload in a different character set other than UTF-8.

Most applications have defensive mechanisms in place to detect XXE payloads. However, these filters often only check for malicious patterns in standard character sets, such as UTF-8. By encoding your XXE payload in UTF-7, or any other supported character set, a threat actor can slip past these defenses undetected while the payload remains functionally identical but appears completely different to security filters. When the XML parser processes it with UTF-7 encoding, it gets decoded and executed, ultimately bypassing the protection. Below is an example of an XXE payload in UTF-7. And read ‘Exploiting JWT vulnerabilities: A complete guide’.

Tip 26: XXE via UTF-7 charset

Tip 27: NoSQLi exploitation via parameter arrays

View the social post here.

‘NoSQL databases are non-relational database systems designed to handle various data models and provide flexible data structures and schemas for storing, retrieving, and managing data. Unlike traditional SQL (Structured Query Language) databases that organize data in tables with rows and columns, NoSQL databases use alternative data structures.’- A complete guide to exploiting advanced NoSQL injection vulnerabilities

If content-type restrictions are blocking your NoSQLi, try this trick. Exploit NoSQL injection through parameter arrays when the application refuses to accept JSON data. If the target only accepts form data (application/x-www-form-urlencoded), you may still be able to send NoSQL query operators such as ‘$ne’. Some request parsing libraries automatically convert parameter arrays to the correct format, ultimately turning form data into objects. By using array notation in your parameters (e.g., token[$ne]=null), you can inject NoSQL operators even when the content-type is restricted.

View the example below.

Tip 27: NoSQLi exploitation via parameter arrays

Tip 28: Hunting for Log4Shell with match and replace rules

View the social post here.

It's been a few years since Log4Shell, an injection attack in Log4J Apache logging software, struck thousands of companies around the world. And despite all the efforts organizations took to patch this critical flaw in their systems, some web services running in 2025 are still vulnerable to Log4Shell, often due to legacy systems still relying on vulnerable versions, (hidden) dependencies, or incomplete remediation.

But, while Log4Shell is still lurking in many applications, manually testing every input is tedious. By setting up a match and replace rule in your proxy interceptor, you can automatically inject Log4Shell payloads into every request, such as in headers like User-Agent.

Tip 28: Hunting for Log4Shell with match and replace rules

Read ‘Exploiting Log4Shell (Log4J) in 2025’ for more information and top tips regarding Log4J.

Tip 29: Scoring easy CSRF bugs

View the social post here.

Even in modern applications that accept data in JSON format, Cross-Site Request Forgery (CSRF) vulnerabilities still persist.

But this simple trick can help bypass backends that fail to properly validate the content-type, allowing us to craft a proof of concept without triggering CORS.

1.              Find a state-changing HTTP request that requires no unique tokens.

2.              Ensure that you can replicate that request without triggering CORS.

3.              Craft your proof of concept.

Tip 29: Scoring easy CSRF bugs

Read ‘CSRF: A complete guide to exploiting advanced CSRF vulnerabilities.’ for additional context around CSRF exploitation.

Tip 30: Exploiting CSRF in GraphQL targets

View the social post here.

Did you know that GraphQL does not include a built-in protection mechanism against CSRF?  Some developers overlook this and leave their GraphQL API susceptible to CSRF attacks.

Here is a simple way to test for GET/POST-based CSRF vulnerabilities in GraphQL.

1. Find a state-changing HTTP request that requires no unique tokens

2. Change the content-type from ‘application/json’ to ‘application/xwww-form-urlencoded’

3. Craft your proof of concept!

Tip 30: Exploiting CSRF in GraphQL targets

Read this article on ‘Five easy ways to hack GraphQL targets’.

Tip 31: Exploiting CORS via whitelisted third-party origins

View the social post here.

We wrap up our 31 tips with a less tested CORS exploitation method.

Developers sometimes whitelist cloud-based coding platforms like GitHub Pages, CodePen, or Replit for development purposes, but forget to remove them in production.

Take advantage of this oversight and host your proof of concept on a whitelisted domain to make cross-origin requests that bypass CORS restrictions, thereby exfiltrating sensitive data or performing unauthorized actions. It's the perfect way to demonstrate impact for CORS vulnerabilities

See a list of examples here.

Tip 31: Exploiting CORS via whitelisted third-party origins

And read ‘CORS: A complete guide to exploiting advanced CORS misconfiguration vulnerabilities’ for more information.

Next steps

You made it! If you've followed along, you should be proud of your consistency and desire to learn! We hope these 31 days of tips help you find more bugs in 2026.

If you have any questions about any of the topics covered in this article or across our social posts, please don’t hesitate to reach out to our team. We are always happy to help. Happy hunting!