chore: add .well-known/security.txt for RFC 9116 compliance

[jaysu66]

Adds .well-known/security.txt per RFC 9116 to improve automated discoverability for security researchers.

References the existing security@databuddy.cc contact and SECURITY.md policy without modifying the current workflow.

Closes #325

[vercel]

@jaysu66 is attempting to deploy a commit to the Databuddy OSS Team on Vercel.

A member of the Team first needs to authorize it.

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: ASSERTIVE

Plan: Pro

Run ID: 89c4e041-b165-423f-bee1-713b51d9c7ef

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[izadoesdev]

Hey @jaysu66 — welcome to Databuddy! Thanks for the contribution 🎉 Great to have you here.

Summary

Adds a .well-known/security.txt file per RFC 9116 with the existing security@databuddy.cc contact, a link to SECURITY.md, and an expiry date of 2027-04-10. Clean, well-scoped change that closes #325.

Review

No security, performance, or type safety concerns — this is a static metadata file with no runtime impact.

🟡 Warning — File location may not be served correctly
The file is placed at .well-known/security.txt in the repo root. For this to actually be accessible at https://databuddy.cc/.well-known/security.txt, it typically needs to live inside the web app's static/public directory (e.g. public/.well-known/security.txt for Next.js). If the deployment pipeline already copies repo-root files into the served directory, this is fine — but worth confirming so security researchers can actually discover it.

🔵 Suggestion — Canonical URL field
RFC 9116 recommends including a Canonical field pointing to the canonical URL of the security.txt file itself (e.g. Canonical: https://databuddy.cc/.well-known/security.txt). Not required, but it helps prevent spoofing and is considered a best practice.

Assessment

Looks good for merge once the file path is confirmed to be served correctly by the web app. The content itself is clean and follows the RFC spec well. Nice PR description too — clear context and linked issue.

[greptile-apps]

Greptile Summary

This PR adds a security.txt file following RFC 9116 to improve security researcher discoverability. The content itself is well-formed (correct Contact, Expires, Policy, and Preferred-Languages fields), but the file is placed at the repository root rather than inside any app's static-file serving directory, so it will never be reachable at /.well-known/security.txt in production.

• P1: The file must be placed in apps/dashboard/public/.well-known/security.txt (and/or the docs app's public/ dir) for Next.js to serve it — the repo root is not served by any application in this monorepo.

Confidence Score: 4/5

Not safe to merge as-is — the file won't be reachable in production until relocated into an app's public directory.

A P1 finding blocks the primary goal of this PR: the security.txt file placed at the repo root is never served over HTTP in this monorepo architecture, making the RFC 9116 addition a no-op. The fix is straightforward (move the file to the correct public/ directory), so the score stays at 4 rather than lower.

.well-known/security.txt — needs to move to apps/dashboard/public/.well-known/security.txt (and/or apps/docs/public/.well-known/security.txt) to be served.

Important Files Changed

Filename	Overview
.well-known/security.txt	Adds RFC 9116 security.txt, but placed at the repo root rather than inside any app's public/ directory — the file will not be served over HTTP as required by the standard.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[Security Researcher] -->|GET /.well-known/security.txt| B{Where is the file served from?}
    B -->|Current: repo root| C[❌ Not served — file unreachable]
    B -->|Correct: app public dir| D[✅ apps/dashboard/public/.well-known/security.txt]
    D --> E[Next.js serves static file]
    E --> F[RFC 9116 compliant response]
    C --> G[404 — no RFC 9116 benefit]

Loading

_{Reviews (1): Last reviewed commit: "chore: add .well-known/security.txt" | Re-trigger Greptile}

[greptile-apps]

File won't be served at /.well-known/security.txt

Placing this file at the repository root does not make it accessible via HTTP. In this monorepo, the Next.js dashboard serves static files from apps/dashboard/public/ — a file needs to live there (and/or in apps/docs/public/) for it to be reachable at https://[domain]/.well-known/security.txt. Without that, the file exists only in version control and no automated scanner or security researcher will actually find it, defeating the RFC 9116 goal entirely.

Move the file to the correct public directory of whichever app owns the primary domain:

apps/dashboard/public/.well-known/security.txt
apps/docs/public/.well-known/security.txt   # if docs is the main public domain

[greptile-apps]

PR targets main instead of staging

The project's CLAUDE.md guidelines specify that PRs should be opened against staging, not main. This PR targets main directly. Consider retargeting to staging per the contribution guidelines.

[jaysu66]

Good catch — moved the file to apps/dashboard/public/.well-known/security.txt so Next.js will serve it at the correct URL, and added the Canonical field per RFC 9116 recommendation. Latest commit: 4e921af.