Adopt / implement modern internet standards for mapcomplete.org

wouterko commented

2026-01-12 20:54:04 +00:00

Hi, I am a frequent user of mapcomplete. It would be great if mapcomplete.org would implement some of the modern internet standards promoted by amongst others internet.nl. This makes the website more robust, available and supportive towards the future internet.

See test results:

https://internet.nl/site/mapcomplete.org/3673105/
https://internet.nl/site/www.mapcomplete.org/3673083/
https://internet.nl/mail/mapcomplete.org/1717236/
https://internet.nl/mail/www.mapcomplete.org/1717240/ (this mailtest is relevant to prevent e-mail spoofing from @www.mapcomplete.org)

While not all individual tests may be relevant per se for mapcomplete.org, I've listed the, in my opinion, most important ones in the table below.

IPv6 makes the site available on modern connections apart from the older IPv4. Since IPv4 is less and less available, it is key for future accessibility of the site (especially from the Global South) (medium, dependent on hosting provider)
DNSSEC Protects against some fundamental DNS design flaws. See: https://www.namecheap.com/support/knowledgebase/subcategory/2232/dnssec/ (medium/hard, dependent on hosting provider)
HSTS the Strict-Transport-Security HTTP-header, which upgrades http > https without possibility of MITM (still trust on first use, easy)
CAA Restricts what CA's can issue TLS certificates, done by adding DNS records (easy)
CSP the Content-Security-Policy HTTP-header that restricts browser functions to those needed by the site (hard to get it perfect, easy to start with a relaxed CSP)
security.txt File that should be published at /.well-known/security.txt to aid in vulnerability disclosure processes (see for example https://openstreetmap.org/.well-known/security.txt (easy)
DMARC, SPF Prevent e-mail spoofing (along with DKIM), added through DNS (easy/medium)
DANE E-mail cert pinning/'HSTS for e-mail', dependent on hosting provider and requires frequent updating (so should be automated) (hard)

Thanks!

Hi, I am a frequent user of mapcomplete. It would be great if mapcomplete.org would implement some of the modern internet standards promoted by amongst others internet.nl. This makes the website more robust, available and supportive towards the future internet. See test results: https://internet.nl/site/mapcomplete.org/3673105/ https://internet.nl/site/www.mapcomplete.org/3673083/ https://internet.nl/mail/mapcomplete.org/1717236/ https://internet.nl/mail/www.mapcomplete.org/1717240/ (this mailtest is relevant to prevent e-mail spoofing from @www.mapcomplete.org) While not all individual tests may be relevant per se for mapcomplete.org, I've listed the, in my opinion, most important ones in the table below. - [x] **IPv6** makes the site available on modern connections apart from the older IPv4. Since IPv4 is less and less available, it is key for future accessibility of the site (especially from the Global South) (medium, dependent on hosting provider) - [x] **DNSSEC** Protects against some fundamental DNS design flaws. See: https://www.namecheap.com/support/knowledgebase/subcategory/2232/dnssec/ (medium/hard, dependent on hosting provider) - [x] **HSTS** the `Strict-Transport-Security` HTTP-header, which upgrades http > https without possibility of MITM (still trust on first use, easy) - [x] **CAA** Restricts what CA's can issue TLS certificates, done by adding DNS records (easy) - [x] **CSP** the `Content-Security-Policy` HTTP-header that restricts browser functions to those needed by the site (hard to get it perfect, easy to start with a relaxed CSP) - [x] **security.txt** File that should be published at /.well-known/security.txt to aid in vulnerability disclosure processes (see for example https://openstreetmap.org/.well-known/security.txt (easy) - [ ] **DMARC, SPF** Prevent e-mail spoofing (along with DKIM), added through DNS (easy/medium) - [ ] **DANE** E-mail cert pinning/'HSTS for e-mail', dependent on hosting provider and requires frequent updating (so should be automated) (hard) Thanks!

pietervdvn commented

2026-01-12 22:47:19 +00:00

Owner

I'm adding IPv6 addresses for the hetzner-hosted items. One server (cache.mapcomplete.org) lives on a residential, IPv4 connection.

@Thibaultmol What is the IPv6 address of panoramax.mapcomplete.org ? (Run ip addr in the terminal and paste the output here)

I'm adding IPv6 addresses for the hetzner-hosted items. One server (cache.mapcomplete.org) lives on a residential, IPv4 connection. @Thibaultmol What is the IPv6 address of panoramax.mapcomplete.org ? (Run `ip addr` in the terminal and paste the output here)

pietervdvn referenced this issue from a commit

2026-01-12 23:01:22 +00:00

Misc: add security policy and security.txt, see #2627

pietervdvn referenced this issue from a commit

2026-01-13 00:48:22 +00:00

Scripts: actually include .well-known, see #2627

Thibaultmol commented

2026-01-15 08:29:20 +00:00

Owner

2a01:4f8:c2c:3cfe::1/64

👍 1

pietervdvn commented

2026-01-19 12:47:35 +00:00

Owner

DNSSEC turned out to be a single checkbox to check at namecheap...

pietervdvn commented

2026-01-26 15:36:30 +00:00

Owner

I will not enable HSTS; this might brick the website completely if the SSL ever gets broken. See this comment. Caddy (on my end) forces users to HTTPS anyway. Browsers nowadays will attempt to use HTTPS first anyway (Firefox does this since ~1year)

I will not enable HSTS; this might brick the website completely if the SSL ever gets broken. See [this comment](https://github.com/caddyserver/caddy/issues/4751#issuecomment-1113617127). Caddy (on my end) forces users to HTTPS anyway. Browsers nowadays will attempt to use HTTPS first anyway ([Firefox does this since ~1year](https://support.mozilla.org/en-US/kb/https-first))

pietervdvn commented

2026-01-26 15:54:54 +00:00

Owner

CSP is handled by setting this in every HTML file with a script. It is impossible to do this via the caddy configuration file: every HTML file has a different set of sources it might connect to (depending on background layers and some special features). This set of URLs is also quite dynamic as the repository of useable background layers has quite some movement.

CSP is handled by setting this in every HTML file with a script. It is impossible to do this via the caddy configuration file: every HTML file has a different set of sources it might connect to (depending on background layers and some special features). This set of URLs is also quite dynamic as the [repository of useable background layers](https://github.com/osmlab/editor-layer-index/) has quite some movement.

👍 1

pietervdvn commented

2026-01-26 16:21:48 +00:00

Owner

security.txt is deployed on the develop branch (and will eventually also be on the main version)

[security.txt](https://dev.mapcomplete.org/.well-known/security.txt) is deployed on the develop branch (and will eventually also be on the main version)

wouterko commented

2026-02-04 20:50:39 +00:00

Author

Thank you very much for taking the time to fix this!! Already great score on the web test now!

@pietervdvn wrote in #2627 (comment):

I will not enable HSTS; this might brick the website completely if the SSL ever gets broken. See this comment. Caddy (on my end) forces users to HTTPS anyway. Browsers nowadays will attempt to use HTTPS first anyway (Firefox does this since ~1year)

I get the viewpoint, yet "this might brick the website completely if the SSL ever gets broken" in my perspective is a feature not a bug. The reason: client-side attempted HTTPS-first is very good, but HSTS is recommended since the client is still vulnerable to man-in-the-middle downgrade attacks (for example by shady wifi networks). Since the client would just continue over HTTP, the connection is now unencrypted. HSTS solves this by caching this "HTTPS-only" property in the browser, making all following connections protected for downgrade attacks. By default, HSTS requires still "trust on first use". If you would want to have no need for trust on first use, you can use the HSTS preload directive: https://hstspreload.org/

Due to HTTPS and replacing certs being so trivial these days, I think the downsides are minimal. If you ever need to get rid of HTTPS for any reason, you could temporarily serve a HSTS header with max-age=0. This resets the cache when someone visits the site.

Just my 2 cents on the topic.

@pietervdvn wrote in #2627 (comment):

security.txt is deployed on the develop branch (and will eventually also be on the main version)

Very nice! Just a small remark: the e-mail address should be preceded with mailto: (according to the RFC this has to be a valid URI)

Thank you very much for taking the time to fix this!! Already great score on the web test now! @pietervdvn wrote in https://source.mapcomplete.org/MapComplete/MapComplete/issues/2627#issuecomment-6221: > I will not enable HSTS; this might brick the website completely if the SSL ever gets broken. See [this comment](https://github.com/caddyserver/caddy/issues/4751#issuecomment-1113617127). Caddy (on my end) forces users to HTTPS anyway. Browsers nowadays will attempt to use HTTPS first anyway ([Firefox does this since ~1year](https://support.mozilla.org/en-US/kb/https-first)) I get the viewpoint, yet "this might brick the website completely if the SSL ever gets broken" in my perspective is a _feature_ not a bug. The reason: client-side attempted HTTPS-first is very good, but HSTS is recommended since the client is still vulnerable to man-in-the-middle downgrade attacks (for example by shady wifi networks). Since the client would just continue over HTTP, the connection is now unencrypted. HSTS solves this by caching this "HTTPS-only" property in the browser, making all following connections protected for downgrade attacks. By default, HSTS requires still "trust on first use". If you would want to have no need for trust on first use, you can use the HSTS preload directive: https://hstspreload.org/ Due to HTTPS and replacing certs being so trivial these days, I think the downsides are minimal. If you ever need to get rid of HTTPS for any reason, you could temporarily serve a HSTS header with max-age=0. This resets the cache when someone visits the site. Just my 2 cents on the topic. @pietervdvn wrote in https://source.mapcomplete.org/MapComplete/MapComplete/issues/2627#issuecomment-6225: > [security.txt](https://dev.mapcomplete.org/.well-known/security.txt) is deployed on the develop branch (and will eventually also be on the main version) Very nice! Just a small remark: the e-mail address should be preceded with mailto: (according to the RFC this has to be a valid URI)

pietervdvn referenced this issue from a commit

2026-02-04 21:41:10 +00:00

Fix: fix security.txt email (add mailto), see #2627

Rows
Columns

Adopt / implement modern internet standards for mapcomplete.org #2627