Friendly Bit - Web development blog

JustHTML is now safe-by-default

2025-12-28T12:00:00+01:00

If you accept HTML from users (comments, profiles, CMS fields), you eventually hit the same problem:

You want to keep some markup.
You really don’t want to ship an XSS.

That’s why JustHTML now includes a built-in, policy-driven HTML sanitizer, and why serialization is safe-by-default.

Safe-by-default serialization#

JustHTML sanitizes when you serialize to HTML or Markdown:

from justhtml import JustHTML

user_html = (
    '<p>Hello <b>world</b> <script>alert(1)</script> '
    '<a href="javascript:alert(1)">bad</a> '
    '<a href="https://example.com/?a=1&b=2">ok</a></p>'
)

doc = JustHTML(user_html, fragment=True)

print(doc.to_html())
print()
print(doc.to_markdown())

This drops <script> and strips dangerous URLs:

<p>Hello <b>world</b>  <a>bad</a> <a href="https://example.com/?a=1&amp;b=2">ok</a></p>

Hello **world** [bad] [ok](https://example.com/?a=1&b=2)

Turning it off (trusted input only)#

If the input is trusted and you want raw output, you can opt out:

print(doc.to_html(safe=False))
print(doc.to_markdown(safe=False))

Custom allowlist policies#

The default policy is intentionally conservative, but you can provide your own SanitizationPolicy. Here’s a small example that only allows p, b, and a[href], and only allows https links:

from justhtml import JustHTML, SanitizationPolicy, UrlRule

policy = SanitizationPolicy(
    allowed_tags=["p", "b", "a"],
    allowed_attributes={"*": [], "a": ["href"]},
    url_rules={
        ("a", "href"): UrlRule(allowed_schemes=["https"]),
    },
)

doc = JustHTML(user_html, fragment=True)
print(doc.to_html(policy=policy))

If you’re sanitizing a full document, safe serialization keeps <html>, <head>, and <body> wrappers. For snippets, pass fragment=True to avoid implicit document wrappers.

There are also a couple of knobs that tend to show up in real systems:

URL proxying (for example, rewriting https://example.com/… to /proxy?url=…)
Optional inline styles, with an allowlist of CSS properties and conservative value checks

Why I built `justhtml-xss-bench`#

If you’ve worked on sanitizers before, you know the hard part isn’t writing a policy — it’s knowing what the browser will actually do with the result.

So I built a tiny benchmark harness: [justhtml-xss-bench](https://github.com/EmilStenstrom/justhtml-xss-bench/).

What it does:

Takes a payload vector and a sanitizer.
Sanitizes the payload.
Embeds the sanitized output into the initial HTML page ("server-side" style).
Loads it in a real Playwright browser engine.
Fails the case if JavaScript executes (including signals like dialogs or attempted external script fetches).

It ships with 7,000+ real-world XSS vectors and can be used to compare JustHTML’s output with other sanitizers.

If you want to explore it locally, the CLI looks like this:

# Run all vector files in ./vectors against the default sanitizer set
xssbench

# Limit to one engine
xssbench --browser chromium

# List available sanitizers
xssbench --list-sanitizers

# Run a subset
xssbench --vectors vectors/bleach.json --sanitizers noop

Threat model (what “safe” means)#

JustHTML’s sanitizer aims to prevent script execution when you sanitize untrusted HTML and embed the result into an HTML document as markup.

It does not make it safe to drop the output into JavaScript string contexts, CSS contexts, URL contexts, or other non-HTML contexts — those need their own escaping/handling.

If you want the details, see the JustHTML sanitization documentation:

https://github.com/EmilStenstrom/justhtml/blob/master/docs/sanitization.md

And the benchmark harness repo:

https://github.com/EmilStenstrom/justhtml-xss-bench

How to make e-mail encrypted for everyone

2016-10-28T23:26:00+02:00

Update: For a wholesome look at e-mail security this video from the CTO of ProtonMail: https://vimeo.com/216747532

When you send an e-mail today it's sent in plaintext. This means that when you connect to your local coffee shop's WiFi they can intercept all e-mail that is sent through their router. This is probably not the relationship you have with your barista…

E-mail is way more important than this, and should receive the same privacy protection as the web has with HTTPS. I haven't seen any meaningful progress on e-mail encryption in a long time, so this article is a suggestion of how to get things moving.

The base idea is this: We should make e-mail work just like the web in terms on encryption:

Encryption should be added gradually, without breaking backwards compatibility (interoperability)
Intermediate servers shouldn't be able to read the message (privacy)
Users should be able to keep sending and receiving e-mail like they always have (usability)
E-mail clients and e-mail providers should be able to easily implement the scheme (simplicity)

Encrypt as much as possible of the e-mail message#

For web traffic, we've encrypting everything except the domain name of the site we're connecting to, this is how e-mail should work too. Since we need to know who to send the e-mail to, we should encrypt everything except the recipient address.

Some of you might have read about STARTTLS, a way to make SMTP encrypted. Unfortunately STARTTLS has several problems that makes it unfit to solve the privacy problem:

It only encrypts the message between the many servers your e-mail passes through. Your e-mail is decrypted and exists in plaintext on each of the intermediate servers. If any of the intermediate servers is hacked they get full access to all e-mails passing through. You likely don't have that kind of relationship with your ISP network administrator either…
If any of the intermediate servers doesn't support STARTTLS, the connection is downgraded to plaintext instead. One old server and the whole chain breaks.

We should apply encryption on the client when sending, and decrypt at the recipient. No intermediate servers should get access to the message.

Encrypt with public-key cryptography (without the hassle)#

The best way to handle this encryption is with public-key cryptography, where the sender first fetches the public key of the receiver, sends the message encrypted with that key, and then that the receiver decrypts it using their private key.

People are already sending e-mail this way with PGP, so way not just use this everywhere? It has several big usability problems:

You need to do key management yourself. On the web the browser handles all cryptography for you. You type the address in the browser and everything just works. This is not the case with PGP. Look at this guide in the eyes of a normal person: OpenPGP for a complete beginner - it quickly goes into downloading zipfiles, package managers and using the command line to generate keys.
You need to install software on your computer. Most e-mail providers are moving to the web, having to install a browser plugin just to send e-mail is not the experience we should strive for. I understand that this is means your e-mail provider can read your e-mail, so it won't work for everyone. But I think most people will accept that the same way they accept that their bank can read their bank statement. If we can trade this for usability it's still a HUGE step up for privacy.

Here's how this could be done differently:

Encryption:

For each recipient in the To, Cc, and Bcc fields:
1. Do a lookup against their domain to see if it supports encryption. This should be a new DNS record that points to an address that the e-mail client can use to fetch the public key for a specific user of that domain.
2. Fetch the public key for each of the users of the domain
3. If both the domain has encryption support and the public key can be fetched, show a lock symbol beside that e-mail address to show that the message to that recipient will be encrypted. Clicking the lock can show information about the encryption that will be used, just like browsers do today.
When the message is sent, split it into as many parts as the number of recipients and encrypt each part with that recipient's public key. Send it off to each recipient using the normal protocols. Users on domains that don't support encryption will get messages sent in plaintext, just like today. This ensures support can be added gradually.

Note that for the user nothing changes compared to how they send e-mail today, except that the lock shows up. Web users are slowly learning about the importance of the lock symbol when browsing the web, transfering that knowledge to e-mail too will create a push for e-mail server operators to support encryption.

Decryption:

When the encrypted e-mail reaches the intended recipients e-mail server, that server uses the private key for that user to decrypt the message and (securely) deliver it the the users inbox. The user reads their e-mail like they've always have.

Some may frown reading that I suggest leaving the private key in the hands of your e-mail provider. I agree that this means you lose some privacy to your e-mail provider. The upside here is that we gain a lot of usability. An e-mail provider (such as Gmail) could and an e-mail client (such as Thunderbird) could update all their software tomorrow and all e-mail sent from Thunderbird to Gmail would be instantly encrypted. This removes the burden of normal users to learn about cryptography to be safe on the web.

In summary, these are the changes that needs to happen for e-mail move towards being encrypted by default:

Consequences for e-mail clients#

New features needed:
- Fetch a DNS record for each receiving domain they want to send an e-mail to
- Fetch each receiving user's public key in the background
- And encrypt as much as possible of the outgoing e-mail
- Send the e-mail using the normal protocols
Ways to pitch this to users:
- All e-mail sent to e-mail providers that support this scheme will be encrypted by default, with no effort on your part
- You can easily see which addresses get encrypted messages with the lock icon that you know from browsers
- Increased privacy from prying eyes

Consequences for e-mail providers#

New features needed:
- Add a DNS record that points to their public keys
- Serve the public key of a specific user that the e-mail clients ask for
- Decrypt incoming e-mails using the private key of that user
- Deliver the e-mail using the normal protocols
Ways to pitch this to users:
- All e-mails sent from clients that support this scheme will be encrypted by default, with no effort on your part
- Increased privacy from prying eyes, do you really trust your local coffee shop as much as your e-mail provider?
Business reasons:
- Support privacy without letting go of the chance to serve ads based on the content of the users e-mails. This is a very important point for big players like Gmail that serve ads. Users or course still have the option to use another e-mail provider or add PGP if they want.
- Nothing in this scheme blocks smaller players from making their users safe using the same methods as the big players will.

In summary#

I think this is a very straightforward way to make all e-mail encrypted. If anyone has a better suggestion that balances the needs of users, e-mail clients and e-mail providers differently I'm all ears. But let's not let this privacy travesty go on much longer…

Hur säkra är svenska banker? (Swedish)

2015-03-01T19:22:05+01:00

Säkerheten varierar stort bland svenska banker. Bankens storlek hänger inte ihop med hur väl dom hanterar säkerheten. Ingen av de fyra storbankerna kom med på topplistan. Några små banker finns med i toppen, några riktigt stora finns i botten.

För att testa bankernas säkerhet gav jag varje bank två olika betyg:

Kryptering: Krypteras trafiken mellan dig och banken ordentligt?

Utan kryptering kan andra se de uppgifter som du skickar till banken, personnummer, lösenord, och koder. Dessa relativt tekniska tester görs med hjälp av SSL Labs. Betygsskalan kommer direkt från SSL Labs och går från A-F, där A är bäst. Notera att jag testar inloggningssidan, inte startsidan.
Visuellt: Ser allt ok ut i webbläsaren?

Det finns gott om guider som lär ut webbsäkerhet till ovana användare. Här tittar jag på om banksajterna är konfigurerade så att allt ser OK ut för en vanlig användare. Har sajten grönt hänglås? Jag har använt samma betygsskala: A-F, där A är bäst.

Bankerna kommer från Finansinspektionens lista över bankaktiebolag och medlemsbanker. De lokala sparbankerna har inte tagits med, och inte heller de som främst riktar sig till företag. Testet gjordes 2015-02-28. Rådata för testet finns här, inklusive länkarna till SSL Labs där du kan se testresultatet själv.

Uppdaterat:#

Eftersom denna artikel fått väldigt bra spridning har flera av bankerna hört av sig. Ofta med konkreta förbättringar de har genomfört på grund av min artikel. Här hittar du en tidslinje över hur artikeln har ändrats över tid.

2015-03-03: Inga fler uppdateringar görs från detta datum och framåt...
2015-03-02: Danske Bank tillagd. Dom får tyvärr bara ett C.
2015-03-02: Kontrollerade stöd för DNSSEC: Landshypotek, Marginalen, Danske Bank, och Länsförsäkringar är de enda som stödjer det.
2015-03-03: Rättade felaktig klassificering av SBAB. Jag hade testat startsidans certifikat, inte inloggningssidans.
2015-03-04: SBAB Bank har förbättrat sitt certifikat på startsidan.
2015-03-04: Länsförsäkringar har uppdaterat sitt certifik och får nu ett B.
2015-03-05: Ekobanken har uppdaterat sitt certifikat och får nu ett A.
2015-03-05: Forex bank har uppdaterat sitt certifikat och får nu ett A.
2015-03-05: Santander Consumer har släppt en ny internetbank och hamnar nu på B.
2015-03-06: MedMera Bank har uppdaterat sitt certifikat och får nu ett B.
2015-03-07: Carnegie Bank har uppdaterat sitt certifikat och får nu ett A
2015-03-08: SBAB Bank har gjort ytterligare uppdateringar och blir första bank med A/A. Full pott!
2015-03-12: JAK Medlemsbank har uppdaterat sitt certifikat och får nu ett B.
2015-03-12: Länsförsäkringar har uppdaterat sitt certifikat och får nu ett A-.
2015-03-18: Swedbank kör nu HTTPS på sin startsida.
2015-04-11: Resurs Bank har uppdaterat certifikatet på sin startsida, och kräver nu även https där. Inloggningscertifikatet kommer att uppdateras också, men är inte klart ännu.
2015-04-24: Skandiabanken kör nu HTTPS på sin startsida.
2015-10-28: Resurs Bank har flyttat sin inloggningssida till egen domän och certifikat.

Bankerna med bäst säkerhet (A):#

Fantastiska resultat för alla dessa fyra banker. Krypteringen uppfyller best practices och du kan sova gott med vissheten att din bank är bland Sveriges bästa.

	Kryptering	Visuellt
Betyg	Not	Betyg	Not
SBAB	A	1	A
Skandiabanken	A	1	A
Resurs Bank	A	1	A
Landshypotek	A	2	B	4
Carnegie Investment Bank	A		B	4
Ekobanken	A		B	4
Forex Bank	A		B	4
Länsförsäkringar Bank	A-	3	A
Marginalen Bank	A-	3	A
Nordnet	A-	3	A

Noter:

Grattis till SBAB Bank, Skandiabanken och Resurs Bank som får A i båda kategorier.
En extra eloge till Landshypotek som får noll varningar från SSL Labs.
Flera banker får A minus eftersom de saknar stöd för Forward Secrecy. Förenklat innebär det att krypteringsmetoden ändras över tid, så att någon som avlyssnat trafik till en sajt för länge sedan inte kan dekrypteras den om sajten hackas senare. Totalt har endast tre svenska banker har stöd för detta (Landshypotek, Skandiabanken och ICA Banken (se nedan)). Bra jobbat!
Flera bankers startsidor saknar kryptering. Eftersom inloggningssidorna är krypterade är detta inte katastrof, bara olyckligt. Att ha kryptering på hela sin webbplats är en bra idé eftersom kunden vänjer sig vid att se det gröna hänglåset så länge dom har med banken att göra.

Bankerna som nästan kom med på topplistan (B):#

Även här får bankerna bra betyg. Anledningen att dom missar topplistan är att samtliga banker i denna lista har problem med vilka krypteringsalgoritmer/protokoll dom stödjer. Det är enkelt egentligen: Om en krypteringsmetod är bevisat osäker (t.ex. RC4 eller SSL3) ska den plockas bort. Att ha den kvar innebär att kunderna luras att tro att deras uppkoppling mot banken är säker trots att den inte är det.

	Kryptering	Visuellt
Betyg	Not	Betyg	Not
ICA Banken	B	1	A
Avanza	B		A
MedMera Bank	B		A
Santander Consumer	B		A
JAK Medlemsbank	B		A
Swedbank	B		A
SEB	B		B	2
Volvofinans Bank	B		B	2
Ikanobanken	B		B	2
Nordea Bank AB	B		B	2
Handelsbanken	B		B	2

Noter:

ICA Banken är nästan med i topplistan ovan. Dom krypterar sin startsida, dom stödjer Forward Secrecy, och är dessutom den enda bank som stödjer HTTP Strict Transfer Security. Tyvärr används krypteringsalgoritmen RC4, en algoritm som inte är säker alls. Har du en lite äldre webbläsare kan du alltså bli lurad att allt ser bra ut, trots att trafiken mellan dig och banken relativt enkelt kan avlyssnas. ICA Banken borde helt enkelt stänga av stöd för RC4, be sina användare att uppgradera sin webbläsare, och inta toppositionen i denna lista.
Flera bankers startsidor saknar kryptering. Eftersom inloggningssidorna är krypterade är detta inte katastrof, bara olyckligt. Att ha kryptering på hela sin webbplats är en bra idé eftersom kunden vänjer sig vid att se det gröna hänglåset så länge dom har med banken att göra.

Bankerna som du borde vara orolig för (C):#

Någonstans här är det dags att börja bli orolig. Dessa banker har gemensamt att dom inte hanterar sin kryptering på rätt sätt. Extra olyckligt är det ställt för OK-Q8 Bank som använder en färdig produkt från EDB och ändå får sämst betyg av C-bankerna.

	Kryptering	Visuellt
Betyg	Not	Betyg	Not
Danske Bank	B		F	2
Erik Penser	C	3	F	4, 5
OK-Q8 Bank	C	3	F	1, 4, 6

Noter:

OK-Q8 Bank lyckas vända något bra - det gröna hänglåset - till något mindre bra. Ett klick på det gröna hänglåset visar vem som garanterar säkerheten på webbplatsen. Bakom OK-Q8 Bank står EVRY AS, ett norskt bolag, som garant.Hur ska en kund veta att det är banken som står bakom det certifikatet, att dom har kommit till rätt sajt? Underkänt.
Danske Bank har bara har satsat på en grått hänglås. Den gråa hänglåset betyder att uppkopplingen är krypterad, men inte vem som står bakom den (så kallad Extended Validation). För något så känsligt som banktjänster ska ett riktigt EV-certifikat användas.
Flera banker verkar inte ha skyddat sig från ett säkerhetshål som döpts till POODLE. Google publicerade detaljer om hur man använder sig av hacket redan i oktober 2014. Att det fortfarande finns banker som inte skyddat sig är anmärkningsvärt.
Flera bankers startsidor saknar kryptering. Eftersom inloggningssidorna är krypterade är detta inte katastrof, bara olyckligt. Att ha kryptering på hela sin webbplats är en bra idé eftersom kunden vänjer sig vid att se det gröna hänglåset så länge dom har med banken att göra.
Erik Penser gör kapitalfel på sin inloggningssida, den ser inte ut att vara krypterad. Som kund ska man aldrig skriva in känsliga inloggningsuppgifter på en webbsida som saknar hänglås. Erik Penser gör visserligen rätt bakom kulisserna (inloggningssidan ÄR krypterad) men det visas inte upp för kunden alls. Gör om, gör rätt.
OK-Q8 Bank och Danske Bank visar inte något som helst hänglås i webbläsaren. Anledningen är att inloggningssidan hämtar bilder över en helt okrypterad uppkoppling. Det gör att man väldigt lätt kan se att du loggar in på banken. Danske Bank döljer dessutom denna miss genom att visa inloggningssidan i en popupruta. Riktigt illa.

Bankerna du borde undvika (F):#

Dags för bottennoteringarna. Det gemensamma för dessa banker är att dom har allvarliga problem med sin kryptering. Du kan därför inte kan lita på att trafiken till deras sajter är ordentligt krypterad.

Inga banker ligger på den här positionen längre. Bra jobbat av alla fem!

Slutligen#

Det finns väldigt många andra kriterier att sätta betyg på, men jag nöjer mig med detta denna gång. Kanske finns det någon annan som vill fortsätta jämförelsen på sin egen blogg?

Vill du diskutera resultaten vidare finns jag på Twitter: @EmilStenstrom