Add .well-known/security.txt file #2062

Stormheg · 2025-05-01T12:54:30Z

This is a PR for an action I took as member of the Website working group, see meeting notes here: https://forum.djangoproject.com/t/website-team-meeting-notes/40655

I spoke with @bmispelon yesterday during Wagtail Office Hours and he mentioned we can serve static files like this through a nginx rule which are controlled by the ops team. We apparently already do this for other 'static' content files. This has yet to be set up.

I chose to put this in a .well-known folder in the project root for visibility.

Consider the contents of the security.txt file an initial draft and open to discussion.

Stormheg · 2025-05-01T12:58:56Z

djangoproject/tests.py

+                "The security.txt file is close to expiring. \
+Please update the 'Expires' line in to confirm the contents are \
+still accurate: {}".format(
+                    FILE_PATH
+                ),


'E501 line too long' is set up in this project (one that I generally disable) – any suggestions on how to clean this up?

You could build the string outside of the assert method or shorten the message.

Is a test needed for this though? How about a calendar reminder? It seems like one day this will start failing the test suite on every PR/commit.

Fair point @adamzap – I've downgraded this to a warning instead of a hard fail. This is is still fairly visible and does not rely on someone keeping on track of calendar event.

How does this sit with you?

bmispelon

Thanks for working on this Storm! 🎸

I've left a few minor stylistic comments inline, but I've also got some more general questions:

I originally said that we could use an nginx config to link to the file, but after thinking about it some more I realized that it's going to be more complicated than I'd initially thought, because the security.txt is located inside the container. So I think a dedicated view is probably going to be better here.
Does the file need to be served under all subdomains (www, docs, code, dashboard), or only some of them?
As Adam noted, I'm not sure a failing test is the right type of warning for this (though I appreciate that you thought about emitting a warning at all, that's good forward thinking). Did you explore other types of warnings for this and if so, could you walk us through what made you pick a test? On the top of my head, this could also potentially be a system check, a management command that we'd run regularly on the production server, or maybe even some kind of scheduled github action (I know django/django has some of those for example).
edit: Oh, and also I think the folder should be named well-known: we don't need it to be hidden.

I'm happy to brainstorm or chat through things on Discord, or even on a call if you'd prefer. Just let me know.

bmispelon · 2025-05-02T11:15:08Z

.well-known/security.txt

+Policy: https://www.djangoproject.com/security/
+Contact: https://www.djangoproject.com/security/
+Expires: 2026-12-31T00:00:00.000Z
+Encryption: https://keys.openpgp.org/vks/v1/by-fingerprint/AF3516D27D0621171E0CCE25FCB84B8D1D17F80B


For the sake of a future maintainer, it would be nice to document where one could find a link to the most up-to-date key. I was going to suggest a comment above this line, but I'm not sure if that's the best place for such documentation 🤔 (happy to hear other suggestions)

I don't think this file might be a good place for putting that comment, since this file is targetted more towards people who want to report a security issue. It should ideally be there somewhere in a readme for contributors and maintainers. Maybe SECURITY.md (which I am planning on adding)?

Sounds like something worthy of enabling the repo wiki for?

Since this is now a Django template, we could use a Django template comment so the comment only appears in source code. How does that sound?

bmispelon · 2025-05-02T11:16:40Z

.well-known/security.txt

+
+# Hello security researcher!
+# We appreciate your help in keeping Django secure.
+# Please report security issues that concern the Django website (djangoproject.com) to ops@djangoproject.com


This seems to contradict the Policy and Contact directives above which state that one should email security@djangoproject.com.

I think we could change this with the website WG email: website-wg@djangoproject.com to keep the security issues for Django itself separated for the fellows, but the security page need a new line somewhere to mention that security issues related to the website are supposed to be send to this email instead.

Thanks, I've changed the wording in the file to make clear what should be reported where.

djangoproject/tests.py

sabderemane

Looks good, thank you @Stormheg ! I added one comment for a small change, including the security page.

sabderemane · 2025-05-06T13:55:22Z

.well-known/security.txt

+
+# Hello security researcher!
+# We appreciate your help in keeping Django secure.
+# Please report security issues that concern the Django website (djangoproject.com) to ops@djangoproject.com


I think we could change this with the website WG email: website-wg@djangoproject.com to keep the security issues for Django itself separated for the fellows, but the security page need a new line somewhere to mention that security issues related to the website are supposed to be send to this email instead.

Stormheg · 2025-06-05T15:10:15Z

Thanks for the reviews so far all 👍

I'm going to rework the contents based on #2086

@bmispelon

I originally said that we could use an nginx config to link to the file, but after thinking about it some more I realized that it's going to be more complicated than I'd initially thought, because the security.txt is located inside the container. So I think a dedicated view is probably going to be better here.

Alright, will move it into a view.

Does the file need to be served under all subdomains (www, docs, code, dashboard), or only some of them?

I'd say the file specifically relates to the security of the application running on that domain, so the answer would be: probably, yes.

I'm not sure what the architecture is behind the different subdomains, but if they are all served from this repository we can serve the same file for all of them.

As Adam noted, I'm not sure a failing test is the right type of warning for this (though I appreciate that you thought about emitting a warning at all, that's good forward thinking). Did you explore other types of warnings for this and if so, could you walk us through what made you pick a test? On the top of my head, this could also potentially be a system check, a management command that we'd run regularly on the production server, or maybe even some kind of scheduled github action (I know django/django has some of those for example).

@bmispelon @adamzap regarding the test case, I was looking for something that is visible and explicit and this is the first thing I came up with. I did not put in any more thought in it than that. What warning mechanism would you prefer to see instead?

edit: Oh, and also I think the folder should be named well-known: we don't need it to be hidden.

Good catch, lol. I have hidden folders enabled on my mac and forgot that's a convention.

See https://securitytxt.org/ for more info.

- Serve from a view, nginx is not going to handle this for us. - Make clear what should be reported to the security@djangoproject.com and what should be reported to the website working group - Downgrade security.txt expiration test to a warning instead of a hard fail.

Stormheg

@bmispelon @adamzap @sabderemane I've updated the PR with your feedback - thank you

Stormheg · 2025-08-10T12:27:34Z

djangoproject/templates/well-known/security.txt

+# Please report security issues that concern this website (djangoproject.com)
+# to the website working group: website-wg@djangoproject.com
+# This helps us make sure your report is directed to the right people.
+# You can find guidelines for reporting website security issues here: https://github.com/django/djangoproject.com/blob/main/.github/SECURITY.md


Note: this url doesn't exist yet. Assumes #2086 is merged.

Stormheg requested a review from bmispelon May 1, 2025 12:54

Stormheg commented May 1, 2025

View reviewed changes

bmispelon reviewed May 2, 2025

View reviewed changes

sabderemane reviewed May 6, 2025

View reviewed changes

SaptakS mentioned this pull request May 30, 2025

Adds SECURITY.md to outline our security policies #2086

Draft

Stormheg added 2 commits August 10, 2025 13:32

Add .well-known/security.txt file

b2b8765

See https://securitytxt.org/ for more info.

Add test to check security.txt expiration

ad8da62

Stormheg force-pushed the security-txt-file branch 2 times, most recently from bf13b2c to 0162422 Compare August 10, 2025 12:22

Stormheg force-pushed the security-txt-file branch from 0162422 to 318757e Compare August 10, 2025 12:29

Stormheg commented Aug 10, 2025

View reviewed changes

Uh oh!

Add .well-known/security.txt file #2062

Are you sure you want to change the base?

Add .well-known/security.txt file #2062

Uh oh!

Conversation

Stormheg commented May 1, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

bmispelon left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

sabderemane left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Stormheg commented Jun 5, 2025

Uh oh!

Stormheg left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

bmispelon left a comment •

edited

Loading