🔐 Security policy

Report to

radio@ericade.net

Other way to reach us

erik.zalitis.se

Languages

English or Swedish

Encryption key

None published yet (what to do instead)

Bug bounty

No, but we will credit you if you want

Machine-readable

security.txt (RFC 9116)

Version

1.0

Last updated

9 October 2026

If you look for vulnerabilities in good faith and keep to this policy, we consider your research authorised. In particular:

• We will not report you to the police or take legal action against you over research that follows this policy.
• We will not hold you responsible for breaking terms of use or other restrictions of ours that would otherwise get in the way of good-faith testing, as long as you keep to this policy.
• If somebody else takes legal action against you over research that followed this policy, we will make it known that your work was authorised by us.
• We will work with you to understand and fix the problem, and we will not use what you tell us against you.

This promise covers only the systems listed as in scope, which are ours. We cannot authorise testing of anybody else’s systems, including the third-party services we use. If you are unsure whether something you want to do fits this policy, ask us first at radio@ericade.net.

ericade.radio is a small, independent station. The same servers that you test also play music to real listeners around the clock, so please:

• Tell us promptly once you have found a real or possible vulnerability.
• Do only what you need to prove the problem. Once you have shown that it exists, stop.
• Use accounts of your own. You may create test accounts — please put sectest in their user names so we can tell them apart. If you need two accounts to test access between users, create both yourself.
• Keep your traffic gentle. Stay below about one request per second per host, and back off when you get an HTTP 429 Too Many Requests. Our API limits by address, and a flood from you slows the site down for every listener.
• Leave the streams and the chat room for listeners. Open no more than a couple of connections at a time to the live streams and the chat; both have a limited number of places.
• Keep test content harmless and short-lived. Comments and chat messages are seen by other people. If you have to test them, post as little as you can, nothing offensive and nothing that runs in another visitor’s browser beyond a harmless proof such as an alert(), and remove it afterwards or tell us where it is.
• Keep the details to yourself until the problem is fixed or we have agreed on a date (see disclosure).

The following are not covered by this policy and are not authorised:

• Denial of service: anything that slows down, overloads or interrupts the website, the API, the streams or the chat, including load testing and stress testing.
• Taking over, using or trying to log in to anybody else’s account, and guessing or brute-forcing passwords.
• Viewing, copying, changing or deleting data that is not yours beyond what is strictly needed to show the problem — see personal data.
• Using administrator functions you have gained access to: changing or deleting songs, artists, news or podcast episodes, moderating comments, sending station messages, running maintenance jobs or changing anybody’s privileges. Show that you could, and stop there.
• Interfering with the broadcast: taking over or replacing a live stream, or changing what is played on the air.
• Leaving anything behind: back doors, web shells, extra accounts with raised privileges, or changes that keep working after your test.
• Social engineering, phishing or impersonating the station or its people, towards us, our listeners or our providers.
• Physical attacks, and attacks on our hosting provider’s facilities or staff.
• Spam, and mass automated posting to comments, chat, sign-up or contact forms.

In scope

Systems run by ericade.radio:

• radio.ericade.net — this website, including the account pages, comments, the chat window, the webplayer and /trackdownload/.
• ericade.radio and ericade.net — the station’s other addresses.
• api.ericade.net — the API behind the website, including its WebSocket feeds (/ws/stationdata and /ws/chat).
• stream.ericade.radio and the live streams under /sc/stream/ — for the way we have set them up. A flaw in the streaming server software itself belongs with its vendor.
• Any other host name under ericade.net or ericade.radio that is run by the station.

Out of scope

Services run by others, even where we use them or link to them. Please report problems with them to their owners:

• Our Discord server, and our pages and channels on X (Twitter), Facebook, Twitch and YouTube.
• Directories and players that carry the station or the podcast, such as Zeno.FM and Apple Podcasts, and the podcast statistics service OP3.
• SceneID, the login service we offer as an alternative, and other single sign-on providers.
• Third-party scripts, fonts and analytics loaded by our pages (for example Font Awesome and Microsoft Clarity), and the content delivery networks they come from.
• Any other website that we link to.

If you find that one of our settings makes a third-party service unsafe for our listeners, that is in scope and we would like to hear about it.

Public by design

Some things look sensitive but are meant to be open to everybody, so a report that they are reachable is not a vulnerability on its own: the live streams, the station-data WebSocket feed, the public music catalogue and podcast data, the access token that /get-token/ hands every visitor for reading that data, the RSS feeds, the M3U playlists and the playable audio. What is in scope is anything that lets you go further with them — to change something, to reach data that is not public, or to act as somebody else.

Unless you can show a real way to harm the station or its users with them, we do not treat these as vulnerabilities. You are welcome to mention them, but they will usually be closed without a fix:

• Output from automated scanners, without a proof that the finding is real.
• Missing or “weak” HTTP security headers, cookie flags or TLS settings, on their own.
• Software names and version numbers in headers, banners or error pages.
• Clickjacking on pages without any action worth tricking somebody into.
• Cross-site request forgery on forms that change nothing of importance.
• Self-XSS, and anything that needs the victim to paste code into their own browser.
• Missing SPF, DKIM or DMARC records, without a demonstrated way to spoof our mail.
• Rate limits that are missing or generous on actions that do not matter for security.
• Problems that need a rooted, jailbroken or already-compromised device, physical access, or an outdated browser.
• Things listed as public by design.

Please do not report a vulnerability in a comment, in the chat, on Discord or on social media: those are public, and anybody could use what you write before it is fixed.

What to include

1. The address, endpoint or feature that is affected.
2. What kind of problem it is, and what an attacker could do with it.
3. Step-by-step instructions to reproduce it, with the requests, responses, screenshots or a short proof of concept that you used.
4. When you tested (with the time zone) and the IP addresses you tested from, so that we can tell your traffic apart from a real attack in our logs.
5. Whether you would like to be credited, and under which name or handle.

A short report that we can reproduce is worth more than a long one that we cannot. You can write in English or in Swedish.

Sending sensitive details

We have not published an encryption key yet. Please keep passwords, tokens, session cookies and other people’s personal data out of your first e-mail. Describe what you found instead, and we will agree with you on a safe way to send the rest.

The station is run by a very small team, so we give you times we can keep:

We will treat your report and your identity as confidential, and we will not pass your details on to anybody without your permission.

We follow coordinated disclosure. Please give us the time to fix a problem before you publish anything about it:

• We aim to fix problems within 90 days of your report. Once the fix is live, you are free to publish your findings.
• If we need longer, we will tell you why and agree on a new date with you. If we stop answering you altogether, you may publish once the 90 days are over.
• If a problem is already being used in attacks, we may need to move faster, and we may tell our listeners about it before the 90 days are over.
• Please leave out personal data and anything that would help somebody attack a part of the station that has not been fixed yet.
• If you want credit, we will name you, with the name or handle you choose, when we tell people about the fix. If you would rather stay anonymous, we will respect that.

The station holds some personal data about its listeners: accounts and their e-mail addresses, profiles, comments, chat messages and, in its logs, the addresses of people who connect. That data is protected by the EU’s General Data Protection Regulation (GDPR), and it belongs to them, not to us or to you. If you come across any of it:

• Stop, and look at no more of it than you need to show the problem.
• Do not copy, keep or share it. Where you need to show it to us, redact it (for example the middle of an e-mail address).
• Tell us straight away, so that we can meet our own duties under the GDPR.
• Delete anything you have kept once we have your report.

We use the personal details in your report (your name, your e-mail address and what you tell us) only to handle the report and to credit you if you want it, and we delete them when we no longer need them for that.

ericade.radio is a hobby station with no budget for a bug bounty, so we cannot pay for reports. What we can offer is our sincere thanks, a mention when we tell people about the fix if you want one, and a station that is safer for everybody who listens to it.

Please do not ask for payment in return for the details of a vulnerability. A report that comes with a demand is extortion, and it is not covered by this policy.

We may update this policy as the station changes. The version in force is always the one on this page, and every change is listed below. Research you have already started is covered by the version that was in force when you started it.

Thank you for helping to keep ericade.radio and its listeners safe.