From 78fd60a52929da97eb8dae7666c1cd32512f0bfd Mon Sep 17 00:00:00 2001
From: David Levi <130691697+zerotrustdavid@users.noreply.github.com>
Date: Sat, 22 Aug 2026 04:07:50 +0000
Subject: [PATCH] Correct two documented claims about the Web3Forms key

Both files described the key more protectively than the facts support, and
one of them was simply untrue.

.env.example claimed the key was "kept out of the repo so this public
repository does not ship a ready-made endpoint for anyone to post to". An
earlier commit in this repository's history contains a real key, so that
statement was false at the time it was written. It now says what is
actually true: the value is publishable, it is readable from the deployed
site by anyone viewing source, keeping it out of the source tree is hygiene
rather than confidentiality, and one commit in history contains a real one.

It also now records that the value is inlined at build time, so changing it
in hosting does nothing to an existing deployment without a redeploy. That
behaviour cost real time to rediscover.

SECURITY.md presented the Web3Forms domain restriction as though it settled
the question. It is enforced on a request header, which any client can set,
so it raises effort rather than preventing abuse. The wording no longer
implies otherwise, and the invitation to report abuse now explicitly
includes getting past that restriction.

A documented control that does not hold is worse than no claim at all,
particularly in a repository published to demonstrate practice.
---
 .env.example | 24 ++++++++++++++++--------
 SECURITY.md  | 20 ++++++++++++--------
 2 files changed, 28 insertions(+), 16 deletions(-)

diff --git a/.env.example b/.env.example
index 0a7cdab..24f08ac 100644
--- a/.env.example
+++ b/.env.example
@@ -1,13 +1,21 @@
 # Web3Forms access key, used by the feedback form at /feedback.
 #
-# Get it from https://web3forms.com — it is the key tied to the destination
-# inbox. It is a publishable key (it must reach the browser to work, and grants
-# no account access), which is why it carries the NEXT_PUBLIC_ prefix. It is
-# still kept out of the repo so this public repository does not ship a
-# ready-made endpoint for anyone to post to.
-#
-# Set the same variable in Vercel: Project -> Settings -> Environment Variables,
-# for Production, Preview and Development.
+# Get it from https://web3forms.com. It is a publishable value rather than a
+# secret: it has to reach the browser to work, it is compiled into the client
+# bundle, and it grants no account access, which is why it carries the
+# NEXT_PUBLIC_ prefix. Web3Forms treats it as the form's own identifier, and
+# its API reports it as "form_id/access_key".
+#
+# It is kept out of the source tree so that cloning this repository does not
+# hand over a working endpoint by default, and so local and deployed
+# environments can differ. Treat that as hygiene, not confidentiality: the
+# value is readable from the deployed site by anyone who views source, and one
+# earlier commit in this repository's history contains a real one.
+#
+# Set the same variable in Vercel: Project -> Settings -> Environment
+# Variables, for Production, Preview and Development. The value is inlined at
+# build time, so changing it does nothing to a deployment that already exists.
+# Redeploy after changing it, or the old value stays live.
 #
 # Without it the form renders and validates, but submitting reports that the
 # form is not configured rather than silently discarding the message.
diff --git a/SECURITY.md b/SECURITY.md
index 968093e..2c79715 100644
--- a/SECURITY.md
+++ b/SECURITY.md
@@ -37,14 +37,18 @@ site.
 
 ## A note on the Web3Forms access key
 
-The feedback form's access key is a publishable value. It is prefixed
-`NEXT_PUBLIC_`, it is compiled into the client bundle by design, and it is
-therefore visible to anyone viewing source. That is how Web3Forms works and is
-not a vulnerability on its own. Submissions are restricted to this site's
-domain in the Web3Forms dashboard.
-
-If you find a way to abuse it despite that restriction, that is very much in
-scope and worth reporting.
+The feedback form's access key is a publishable value rather than a secret. It
+is prefixed `NEXT_PUBLIC_`, it is compiled into the client bundle by design,
+and it is therefore visible to anyone viewing source. Web3Forms treats it as
+the form's own identifier, so its being visible is not a vulnerability and does
+not need reporting.
+
+Submissions are additionally restricted to this site's domain in the Web3Forms
+dashboard. That restriction is worth having, but it is enforced on a request
+header, so it raises the effort required rather than preventing abuse outright.
+
+If you find a way to abuse the form, including past that restriction, that is
+in scope and worth reporting.
 
 ## Reporting an incorrect tax figure