Sally web server · Security

Security policy

We want Sally, and every site on it, to be safe for the people who use them, and we welcome reports from anybody who finds a security weakness. This page is our vulnerability disclosure policy: what you may test, how to test it without harming the server or the people who use it, how to tell us what you found, and what you can expect from us in return.

Sally is a private server, run by one person in their spare time: there is no company, no security team and no budget behind it. To report something now, e-mail erik@zalitis.se. Please read the guidelines and the scope first.

Version 1.0 · Updated: 2026-10-10

At a glance

Report to
erik@zalitis.se or radio@ericade.net
Encryption
OpenPGP key for erik@zalitis.se
Languages
English or Swedish
Rewards
No money; we credit you if you want

1. Our promise to you

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 what we run, as listed under scope. Some of the sites on Sally belong to others, and we cannot authorise testing of their applications, nor of anybody else's systems. If you are unsure whether something you want to do fits this policy, ask us first.

2. Guidelines

Sally is one server, and it runs every site on it at the same time, among them a radio station that plays to real listeners around the clock. What slows down one site slows down all of them, 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.
  • Keep your traffic gentle. Stay below about one request per second, scan slowly and one host at a time, and back off when you get an HTTP 429 Too Many Requests or 503 Service Unavailable.
  • Use accounts of your own where a site has accounts, and put sectest in their user names so that we can tell them apart.
  • Keep anything you leave harmless and easy to find. If you find that you can write to the server, show it with one small text file whose name starts with sectest, and tell us where it is.
  • Keep the details to yourself until the problem is fixed or we have agreed on a date (see disclosure).

3. What you must not do

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

  • Denial of service: anything that slows down, overloads or interrupts the server or any site on it, including load testing, stress testing and fast or broad scanning.
  • Guessing your way in: brute-forcing or guessing passwords or keys, on SSH or SFTP or on any login of any site, and trying to log in to anybody else's account.
  • Going beyond the proof: viewing, copying, changing or deleting data or files that are not yours beyond what is strictly needed to show the problem - see personal data. This includes one site's files, logs or configuration reached from another site.
  • Changing the server: its configuration, its software, or the content of any site on it.
  • Using the server against others: as a proxy, as a stepping stone to other systems or networks, to send mail, or to attack anybody else.
  • Leaving anything behind: back doors, web shells, accounts, scheduled jobs or any change that keeps working after your test.
  • Social engineering, phishing, or impersonating us or the people behind any site on Sally.
  • Physical attacks, and attacks on our internet provider, its network or its staff.
  • Spam, and mass automated posting to comments, chat, sign-up or contact forms.

4. Scope

In scope: the server

  • Sally itself, at sally.ericade.net and the.ericade.net and at its IP address: the web server and how it is set up, its TLS settings and certificate, and how it picks the site that answers a request.
  • The server's own site, sally.ericade.net: the portal, the error pages and this policy.
  • The walls between the sites. Anything that lets a request to one site read or change another site's files, logs or settings, or files that should never be public: logs, configuration, version control folders.
  • The other services that answer at the server's address, for the way we have set them up. A flaw in a product itself belongs with its vendor.

In scope: the ERICADE sites

radio.ericade.net, ericade.radio, ericade.net and api.ericade.net are ours and in scope. They have a policy of their own, radio.ericade.net/secpol/, with the rules for their accounts, streams and chat. For those sites, follow that one too; where the two differ, theirs is the one that counts.

The sites hosted for others

api.moleant.com, radioufs.com, itsakerhetspodden.se and zalitis.se run on Sally, but each site belongs to its owner. The server under them is in scope, as above. The sites themselves - their applications, accounts and content - are their owners' to authorise: ask them before you test. If you find a problem in one of them and cannot reach its owner, write to us, and we will pass your report on.

Out of scope

  • Our internet provider and the network in front of the server, our domain registrars and DNS providers, and the certificate authority.
  • Third-party services that the sites use or load, such as analytics, fonts and content delivery networks.
  • Any other website that we link to.

If you find that one of our settings makes a third-party service unsafe for the people who use our sites, 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, so a report that they are visible is not a vulnerability on its own: the list of host names on the server (it is in the TLS certificate and in the public Certificate Transparency logs, and on the portal), the server answering requests by IP address or for unknown names with its own site, the name of the web server software, robots.txt, sitemap.xml and security.txt, and the public pages of each site.

5. What we do not treat as a vulnerability

Unless you can show a real way to harm the server, its sites or the people who use 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.
  • Open ports, on their own, for services that are meant to be reachable.
  • 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.
  • Problems that need a rooted, jailbroken or already-compromised device, physical access, or an outdated browser.
  • Things listed as public by design.

6. How to report

E-mail your report to erik@zalitis.se or radio@ericade.net, with a subject that starts with Security:. We read every message ourselves. To send it encrypted, use erik@zalitis.se and the key below. You can also reach us through erik.zalitis.se. The same contact details, in machine-readable form, are in security.txt (RFC 9116).

Not in public, please

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

What to include

  • The host name, address or feature that is affected.
  • What kind of problem it is, and what an attacker could do with it.
  • Step-by-step instructions to reproduce it, with the requests, responses, screenshots or a short proof of concept that you used.
  • 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.
  • 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.

7. Encrypting your report

Anything sensitive - passwords, tokens, session cookies, other people's personal data, or a working exploit - should go encrypted, with OpenPGP, to erik@zalitis.se. Before you use the key, check that its fingerprint is the one below.

The OpenPGP key for security reports
User IDErik Zalitis <erik@zalitis.se>
Fingerprint5E26 6AAB 6266 36AB 0606 DA4B 58DD 9EAF 8ABD C420
Key typeEd25519 for signing, with a Curve25519 subkey for encryption
Valid10 June 2026 to 10 June 2029
Downloadsally.ericade.net/secpol/pgp-key.txt
Fetch the key, check it, and encrypt a report with GnuPG
gpg --fetch-keys https://sally.ericade.net/secpol/pgp-key.txt
gpg --fingerprint erik@zalitis.se
# must show 5E26 6AAB 6266 36AB 0606  DA4B 58DD 9EAF 8ABD C420
gpg --encrypt --armor -r 5E266AAB626636AB0606DA4B58DD9EAF8ABDC420 report.txt
The public key
-----BEGIN PGP PUBLIC KEY BLOCK-----

mDMEaildXxYJKwYBBAHaRw8BAQdAF0sFv+2Qw2dqnIZGr2QDD9zgGL89erp5kbdU
i3+Lb5W0HkVyaWsgWmFsaXRpcyA8ZXJpa0B6YWxpdGlzLnNlPoi1BBMWCgBdFiEE
XiZqq2JmNqsGBtpLWN2er4q9xCAFAmopXV8bFIAAAAAABAAObWFudTIsMi41KzEu
MTIsMiwxAhsDBQkFpMRBBQsJCAcCAiICBhUKCQgLAgQWAgMBAh4HAheAAAoJEFjd
nq+KvcQgBYsA/0RXhGV4TPbqlSYPqv81XOCKiKFxMCSJJ/XRg58Mmf6pAP47/F/B
J7MhbaKspYQIaJlgQbY1pSfijMMqnP5U9ZYnC7g4BGopXV8SCisGAQQBl1UBBQEB
B0BVbtXoSqutbpxt2J5ZIKdXNf5jjPbOGpVBnN+2yeFqewMBCAeImgQYFgoAQhYh
BF4maqtiZjarBgbaS1jdnq+KvcQgBQJqKV1fGxSAAAAAAAQADm1hbnUyLDIuNSsx
LjEyLDIsMQIbDAUJBaTEQQAKCRBY3Z6vir3EIJEcAQCyUmgXQPBO+YhnCNAmZcLh
jeR2CDxW6HAbrySt+3RdoAEA5uvVzIzWO3M39CQYBVZf6rtIhInS0B5xf9v7A8Gx
jQ4=
=yUim
-----END PGP PUBLIC KEY BLOCK-----

If you cannot use OpenPGP, keep the sensitive details 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.

8. What you can expect from us

Sally is run by one person, so we give you times we can keep:

Our response times, from the day we receive your report
Step Within What happens
Acknowledgement5 working daysWe confirm that we have your report.
First assessment14 daysWe tell you whether we can reproduce the problem and how serious we think it is.
Progress updatesEvery 30 daysUntil the problem is fixed, we tell you how far we have come, or why it is taking longer.
FixAs soon as we canSerious problems first. We tell you when the fix is live, and you are welcome to check it.

We will treat your report and your identity as confidential, and we will not pass your details on to anybody without your permission. The one exception you agree to by reporting a problem in a site hosted for others: we pass the report on to that site's owner, and we ask you first before we tell them who you are.

9. Disclosure and credit

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 the people who use the affected sites about it before the 90 days are over.
  • Please leave out personal data, and anything that would help somebody attack a part of the server that has not been fixed yet.

If you want credit, we will name you on this page under thanks, with the name or handle you choose. If you would rather stay anonymous, we will respect that.

10. Personal data

The server holds personal data about the people who use its sites: in its logs, the addresses of everybody who connects, and on some sites accounts with their e-mail addresses, profiles, comments and messages. 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, and the owner of the site if it is not ours, can meet our 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.

11. Rewards

Sally is run by a private person, with no budget for a bug bounty, so we cannot pay for reports, and we do not hire: a report cannot lead to a job or an assignment either. What we can offer is our sincere thanks, a mention on this page if you want one, and a server that is safer for everybody who uses the sites on 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.

12. Thanks

The people who have reported a security problem to us and wanted to be named. Nobody has been credited yet.

13. Changes to this policy

We may update this policy as the server and its sites change. 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.

Document history
Version Date Change
1.010 October 2026First published.