XSS Hunter Deprecation FAQ

By @IAmMandatory

TL;DR

The XSS Hunter website is deprecated, this means:

• New account registration is now disabled.
• xss.ht subdomains will only be able to either:

• Redirect to another URL.
• Return a configurable static JavaScript payload.

• Users are encouraged to run their own XSS Hunter instances (see xsshunter-express repo) and to redirect their xss.ht subdomain to it.

Why is this happening?

XSS Hunter has been a passion project of mine for many years. I’ve offered the service free-of- charge because I enjoy seeing the success people have had with it for bug bounties and other legitimate security research.

However, XSS Hunter has grown quite large in user base and has become increasingly costly to run. In addition to it being monetarily costly, it has also been very mentally taxing. Taxing both in terms of keeping the infrastructure running, and in responding to abuse queries. Due to my limited mental bandwidth, neither of these things have gotten the attention they deserve.

Lastly I’ve become increasingly uncomfortable with the amount of vulnerability information stored in the service. Ideally I’d like to be storing zero vulnerability information for XSS hunter users, which this deprecation will achieve. This is better for everyone in terms of risk, and is better for me in terms of not having to worry about being beaten with a $5 wrench to hand over XSS Hunter data 🙂.

For all of these reasons, I’ve decided to deprecate the service.

What will happen to all of the stored vulnerability data?

All payload information, correlation injection data, XSS screenshots, etc will be purged shortly after the February 1st deprecation date.

The only information which will continue to be persistently stored is:

• User account information

• This is kept in order to allow for the minimal version of the service to continue running.

• Logging Data

• For the usual abuse handling and service maintenance.

How can I redirect my xss.ht subdomain to my own service?

• Navigate to https://xsshunter.com
• Log in with your XSS Hunter credentials.
• Under the “Forwarding URL” field, enter any https:// URL.
• Click on the "Save Settings" button.
• All future requests to your xss.ht subdomain will be automatically redirected to this URL.

Note: You can undo this redirect by leaving the field empty and saving your settings.

How can I return a static JavaScript payload for my xss.ht subdomain?

• Navigate to https://xsshunter.com
• Log in with your XSS Hunter credentials.
• Under the “Static Payload” field, enter your JavaScript payload.
• Click on the "Save Settings" button.
• All future requests to your xss.ht subdomain will now serve this static payload.

Note: You can undo this redirect by leaving the field empty and saving your settings.

Will my xss.ht subdomain continue to work?

For the foreseeable future following deprecation, you will still be able to do the following:

• Redirect your xss.ht subdomain to an HTTPS URL of your choice.
• Set a static JavaScript payload to be returned for your subdomain.

This will likely be supported for many years to come as the maintenance and cost are  low.

What will the post-deprecation website look like?

Following the deprecation date, the website will be reduced to only have the following functionality:

• Page with information about the deprecation
• Page with abuse contact information
• Login page
• Basic management panel where existing XSS Hunter users can configure the following:

• Account password
• Subdomain Redirect URL
• Static JavaScript payload to return for user subdomain (xss.ht)

Why not hand over XSS Hunter to someone else to run?

Handing the service over to someone else is ethically complicated for a few reasons. The primary reason is that I’d be trusting the new owner with:

• The private information of all XSS Hunter users.
• The vulnerability information for many sites and companies.
• All of the payload-subdomains which XSS Hunter users have utilized for bug hunting over many years.

I don’t want to betray the trust of the XSS Hunter userbase, and I certainly don’t want to expose any of the various services being tested by XSS Hunter users to any increased risk.

For this reason, handing the service off to someone else to run felt untenable. With the deprecation, everyone can choose for themselves what they’d like to do with their subdomains going forward.