From 87eaf2e555d0b49913913f5421569343bd714be5 Mon Sep 17 00:00:00 2001 From: Dickson Date: Sun, 15 Mar 2026 22:43:43 -0400 Subject: [PATCH 01/10] Add web browser hardening guide for Web3 --- docs/pages/guides/endpoint-security/index.mdx | 1 + .../web-browser-hardening.mdx | 206 ++++++++++++++++++ vocs.config.tsx | 1 + 3 files changed, 208 insertions(+) create mode 100644 docs/pages/guides/endpoint-security/web-browser-hardening.mdx diff --git a/docs/pages/guides/endpoint-security/index.mdx b/docs/pages/guides/endpoint-security/index.mdx index f9f5eae7..bd7426e2 100644 --- a/docs/pages/guides/endpoint-security/index.mdx +++ b/docs/pages/guides/endpoint-security/index.mdx @@ -11,4 +11,5 @@ title: "Endpoint Security" ## Pages +- [Web Browser Hardening for Web3](/guides/endpoint-security/web-browser-hardening) - [Zoom Hardening Guide](/guides/endpoint-security/zoom-hardening) diff --git a/docs/pages/guides/endpoint-security/web-browser-hardening.mdx b/docs/pages/guides/endpoint-security/web-browser-hardening.mdx new file mode 100644 index 00000000..e3bc5806 --- /dev/null +++ b/docs/pages/guides/endpoint-security/web-browser-hardening.mdx @@ -0,0 +1,206 @@ +--- +title: "Web Browser Hardening for Web3 | Security Alliance" +description: "Harden browsers for Web3 work with dedicated wallet profiles, minimal extensions, stricter permissions, limited sync, and safer signing habits." +tags: + - Engineer/Developer + - Security Specialist +contributors: + - role: wrote + users: [dickson] +--- + +import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../../components' + + + + +# Web Browser Hardening for Web3 + + + + +## Summary + +> 🔑 **Key Takeaway for Web Browser Hardening:** Treat the browser as part of your signing environment. Use a +> dedicated wallet profile for Web3 activity, keep it almost extension-free, leave phishing protections and updates +> enabled, keep sync limited or off for privileged work, and verify every connect, sign, and approval prompt before +> accepting it. + +For most Web3 teams, browser hardening is less about obscure settings and more about reducing accidental exposure. The +practical baseline is to separate wallet activity from normal browsing, minimize extension risk, keep site permissions +tight, and make origin-checking part of the operating procedure before you connect a wallet or approve a request. + +This page focuses on desktop browser use for Web3 work. It complements endpoint hardening, account security, and wallet +security, but it does not replace them. + +--- + +## For Individuals + +These steps apply to anyone using a browser to access dapps, exchanges, admin consoles, registrars, dashboards, or +wallet extensions. + +### Setup Checklist + +- [ ] Create a dedicated **Wallet / Signing** browser profile for Web3 work +- [ ] For admins, deployers, finance, and treasury roles, use a separate browser in addition to a separate profile if + that is operationally realistic +- [ ] Install only the extensions you actually need in the wallet profile, ideally one wallet extension plus a required + password manager +- [ ] Keep browser phishing and deceptive-site protections enabled +- [ ] Keep secure-connection defaults enabled and avoid downgrading to insecure sites +- [ ] Block notifications, pop-ups, redirects, camera, microphone, and location access by default in the wallet + profile +- [ ] Disable or avoid WebUSB and WebHID access in non-signing profiles unless there is a specific operational need +- [ ] Turn on prompts for download location and avoid automatic file opening +- [ ] Keep the wallet profile unsynced by default unless you have a clear reason to sync it +- [ ] Use stricter cookie and tracking settings so low-trust sites keep less persistent state in your browser +- [ ] Use a password manager, passkeys, or hardware-backed authentication for browser-based accounts +- [ ] Bookmark trusted dapps and admin portals instead of following wallet-related links from chat, email, or ads +- [ ] Review connected sites and token approvals regularly +- [ ] Never store seed phrases, recovery phrases, or private keys in browser password managers or cloud notes + +### Recommended Browser Operating Model + +Use at least two separate contexts: + +- **General profile:** email, chat, docs, research, social media, and routine browsing +- **Wallet / Signing profile:** wallet connections, signing flows, sensitive dashboards, registrars, exchanges, and + admin actions + +This separation reduces session reuse, extension overlap, and the chance that a random page can interact with the same +browser context you use for wallet operations. It is useful workflow separation, not a hard security boundary. Anyone +with access to your unlocked device can still access your browser profiles. + +For higher-risk roles, using a separate browser on top of a separate profile is reasonable defense in depth. Treat that +as an operational safeguard, not as proof of strong isolation. + +### Extension Discipline + +Extensions should be treated as privileged code. + +- Keep the wallet profile to the minimum extension set +- Prefer one primary wallet extension per profile to reduce provider confusion and connection issues +- If the browser or another extension offers a built-in wallet/provider you do not use, disable it in the wallet + profile +- Restrict extension site access where the browser supports it +- Install extensions only from official stores or the wallet vendor's documented source +- Remove unused extensions promptly instead of leaving them installed "just in case" +- Audit extension permissions on a regular cadence instead of assuming an old extension is still safe + +If a site asks you to install a new helper extension, disable browser protections, or re-enter wallet recovery +material, stop and verify the workflow out of band. + +### Daily Web3 Rules + +Make these checks part of your normal process: + +- Navigate to important dapps, exchanges, and admin portals through saved bookmarks or a trusted internal directory +- Before you connect a wallet, confirm the exact domain, requested account, and requested network +- Treat every signature and approval as a high-risk action, even if it is presented as a login or verification step +- Reject prompts you do not understand, especially blind signing requests, unexpected approvals, or urgent "fix your + wallet" messages +- Disconnect sites you no longer use and review token allowances on a regular cadence +- Keep wallet actions out of the general browsing profile, even for "quick" checks + +### Browser Settings That Matter + +Focus on the settings that meaningfully reduce attack surface: + +- **Anti-phishing and reputation protections:** leave them on and treat warnings as blocking signals +- **Downloads:** prompt for save location and do not auto-open files +- **Hardware wallet transports:** keep WebUSB and WebHID access tightly scoped and do not leave broad hardware access + enabled in profiles that are not used for signing +- **Notifications and pop-ups:** block by default, then add narrow exceptions only for sites you trust +- **Clipboard permissions:** avoid granting clipboard access broadly; treat it as sensitive +- **Cookies and tracking:** use stricter defaults so suspicious sites keep less persistent browser state +- **Updates:** let the browser auto-update and restart promptly when updates are pending +- **Sync:** keep privileged profiles unsynced unless your risk model explicitly allows it +- **Authentication:** use passkeys or hardware security keys for email, SSO, source control, cloud, and other accounts + that can be used to pivot into Web3 operations + +--- + +## For Team Members + +These guidelines apply to staff working in a shared organizational environment. + +Team members should: + +- Follow the approved browser and profile model for wallet work instead of improvising per person +- Keep personal browsing, work browsing, and wallet operations separate +- Report unexpected wallet prompts, extension changes, browser warnings, or redirected login flows +- Avoid syncing privileged profiles to unmanaged devices without explicit approval +- Keep browser protections enabled and do not bypass warnings just to complete a task faster +- Escalate suspicious domains, signing prompts, or new dapps before using them with a work wallet + +--- + +## For Admins + +These settings and practices apply to administrators managing browsers for engineers, operators, finance, treasury, or +other privileged users. + +### Managed Browser Baseline + +- [ ] Standardize a supported browser baseline for wallet-related work and keep users on stable channels +- [ ] Require a dedicated wallet profile for privileged workflows +- [ ] For the highest-risk roles, consider a separate dedicated browser in addition to the dedicated profile +- [ ] Default-deny browser extensions and allowlist only approved wallet and password manager extensions +- [ ] Keep browser auto-updates enabled and avoid freezing users on old versions +- [ ] Enforce phishing and deceptive-site protections and decide whether users may bypass warnings +- [ ] Restrict or disable browser sync for privileged profiles, especially on unmanaged devices +- [ ] Set conservative defaults for site permissions, downloads, notifications, pop-ups, redirects, WebUSB, and + WebHID +- [ ] Publish an approved list of high-value dapps, exchanges, admin portals, and registrars for bookmark-based access +- [ ] Require phishing-resistant MFA for the accounts that guard Web3 operations, including email, SSO, code hosting, + cloud, and registrar access +- [ ] Review connected sites, extension inventory, and exceptions during periodic access reviews + +### Admin Notes + +- A dedicated browser is helpful, but it is not a substitute for device hardening, endpoint management, or hardware + wallets +- Document which roles are allowed to sync browser data and under what conditions +- Keep exception handling narrow and explicit; do not let a "temporary" site permission or extension become permanent +- If a team depends on a small set of critical dapps, internal guidance should define the approved domains and expected + connect/sign flow for each one + +--- + +## Web3-Specific Operational Rules + +Browser hardening matters in Web3 because the browser is often the access path to a wallet, not just a place to read +web pages. + +Use these operating rules consistently: + +1. Connect wallets only from the dedicated wallet profile. +2. Verify the origin before connect, sign, approve, or switch networks. +3. Prefer one primary wallet extension per profile. +4. Do not keep stale connected-site sessions around indefinitely. +5. Review token approvals and revoke ones you no longer need. +6. Do not store seed phrases or private keys in browser-based secret storage. +7. Treat "urgent" dapp prompts, fake support chats, and recovery requests as likely phishing attempts. +8. If a prompt is confusing, stop and verify with another team member before signing. + +--- + +## Related Guides + +- [GitHub Security](/guides/account-management/github) +- [Understanding Threat Vectors](/awareness/understanding-threat-vectors) +- [Signing and Verification](/wallet-security/signing-and-verification/signing-verification) +- [Verifying Standard Transactions](/wallet-security/signing-and-verification/verifying-standard-transactions) + +## Further Reading + +- [NIST SP 800-63B: Digital Identity Guidelines](https://pages.nist.gov/800-63-4/sp800-63b.html) +- [W3C WebAuthn Level 3](https://www.w3.org/TR/webauthn-3/) +- [NCSC: Managing Web Browser Security](https://www.ncsc.gov.uk/collection/device-security-guidance/policies-and-settings/managing-web-browser-security) +- [MetaMask: What Is a Secret Recovery Phrase, and How to Secure Your Wallet](https://support.metamask.io/start/what-is-a-secret-recovery-phrase-and-how-to-keep-your-crypto-wallet-secure/) + +--- + + + diff --git a/vocs.config.tsx b/vocs.config.tsx index 0c7d129e..adfa5ec4 100644 --- a/vocs.config.tsx +++ b/vocs.config.tsx @@ -533,6 +533,7 @@ const config = { text: 'Endpoint Security', collapsed: true, items: [ + { text: 'Web Browser Hardening for Web3', link: '/guides/endpoint-security/web-browser-hardening' }, { text: 'Zoom Hardening', link: '/guides/endpoint-security/zoom-hardening' }, ] }, From 88af11c05e3acb73f4fd9942890aa7d574e15cba Mon Sep 17 00:00:00 2001 From: Dickson Date: Fri, 20 Mar 2026 23:12:20 -0400 Subject: [PATCH 02/10] Remove decorative separators from browser hardening guide --- .../endpoint-security/web-browser-hardening.mdx | 15 --------------- 1 file changed, 15 deletions(-) diff --git a/docs/pages/guides/endpoint-security/web-browser-hardening.mdx b/docs/pages/guides/endpoint-security/web-browser-hardening.mdx index e3bc5806..95fb9565 100644 --- a/docs/pages/guides/endpoint-security/web-browser-hardening.mdx +++ b/docs/pages/guides/endpoint-security/web-browser-hardening.mdx @@ -32,9 +32,6 @@ tight, and make origin-checking part of the operating procedure before you conne This page focuses on desktop browser use for Web3 work. It complements endpoint hardening, account security, and wallet security, but it does not replace them. - ---- - ## For Individuals These steps apply to anyone using a browser to access dapps, exchanges, admin consoles, registrars, dashboards, or @@ -133,9 +130,6 @@ Team members should: - Avoid syncing privileged profiles to unmanaged devices without explicit approval - Keep browser protections enabled and do not bypass warnings just to complete a task faster - Escalate suspicious domains, signing prompts, or new dapps before using them with a work wallet - ---- - ## For Admins These settings and practices apply to administrators managing browsers for engineers, operators, finance, treasury, or @@ -165,9 +159,6 @@ other privileged users. - Keep exception handling narrow and explicit; do not let a "temporary" site permission or extension become permanent - If a team depends on a small set of critical dapps, internal guidance should define the approved domains and expected connect/sign flow for each one - ---- - ## Web3-Specific Operational Rules Browser hardening matters in Web3 because the browser is often the access path to a wallet, not just a place to read @@ -183,9 +174,6 @@ Use these operating rules consistently: 6. Do not store seed phrases or private keys in browser-based secret storage. 7. Treat "urgent" dapp prompts, fake support chats, and recovery requests as likely phishing attempts. 8. If a prompt is confusing, stop and verify with another team member before signing. - ---- - ## Related Guides - [GitHub Security](/guides/account-management/github) @@ -199,8 +187,5 @@ Use these operating rules consistently: - [W3C WebAuthn Level 3](https://www.w3.org/TR/webauthn-3/) - [NCSC: Managing Web Browser Security](https://www.ncsc.gov.uk/collection/device-security-guidance/policies-and-settings/managing-web-browser-security) - [MetaMask: What Is a Secret Recovery Phrase, and How to Secure Your Wallet](https://support.metamask.io/start/what-is-a-secret-recovery-phrase-and-how-to-keep-your-crypto-wallet-secure/) - ---- - From 522054129aac2f3d09d1eb4767e2f022810f9609 Mon Sep 17 00:00:00 2001 From: Dickson Date: Fri, 20 Mar 2026 23:29:35 -0400 Subject: [PATCH 03/10] Fix lint in browser hardening guide --- .../guides/endpoint-security/web-browser-hardening.mdx | 7 +++++-- wordlist.txt | 3 ++- 2 files changed, 7 insertions(+), 3 deletions(-) diff --git a/docs/pages/guides/endpoint-security/web-browser-hardening.mdx b/docs/pages/guides/endpoint-security/web-browser-hardening.mdx index 95fb9565..41b0a7dd 100644 --- a/docs/pages/guides/endpoint-security/web-browser-hardening.mdx +++ b/docs/pages/guides/endpoint-security/web-browser-hardening.mdx @@ -32,6 +32,7 @@ tight, and make origin-checking part of the operating procedure before you conne This page focuses on desktop browser use for Web3 work. It complements endpoint hardening, account security, and wallet security, but it does not replace them. + ## For Individuals These steps apply to anyone using a browser to access dapps, exchanges, admin consoles, registrars, dashboards, or @@ -116,8 +117,6 @@ Focus on the settings that meaningfully reduce attack surface: - **Authentication:** use passkeys or hardware security keys for email, SSO, source control, cloud, and other accounts that can be used to pivot into Web3 operations ---- - ## For Team Members These guidelines apply to staff working in a shared organizational environment. @@ -130,6 +129,7 @@ Team members should: - Avoid syncing privileged profiles to unmanaged devices without explicit approval - Keep browser protections enabled and do not bypass warnings just to complete a task faster - Escalate suspicious domains, signing prompts, or new dapps before using them with a work wallet + ## For Admins These settings and practices apply to administrators managing browsers for engineers, operators, finance, treasury, or @@ -159,6 +159,7 @@ other privileged users. - Keep exception handling narrow and explicit; do not let a "temporary" site permission or extension become permanent - If a team depends on a small set of critical dapps, internal guidance should define the approved domains and expected connect/sign flow for each one + ## Web3-Specific Operational Rules Browser hardening matters in Web3 because the browser is often the access path to a wallet, not just a place to read @@ -174,6 +175,7 @@ Use these operating rules consistently: 6. Do not store seed phrases or private keys in browser-based secret storage. 7. Treat "urgent" dapp prompts, fake support chats, and recovery requests as likely phishing attempts. 8. If a prompt is confusing, stop and verify with another team member before signing. + ## Related Guides - [GitHub Security](/guides/account-management/github) @@ -187,5 +189,6 @@ Use these operating rules consistently: - [W3C WebAuthn Level 3](https://www.w3.org/TR/webauthn-3/) - [NCSC: Managing Web Browser Security](https://www.ncsc.gov.uk/collection/device-security-guidance/policies-and-settings/managing-web-browser-security) - [MetaMask: What Is a Secret Recovery Phrase, and How to Secure Your Wallet](https://support.metamask.io/start/what-is-a-secret-recovery-phrase-and-how-to-keep-your-crypto-wallet-secure/) + diff --git a/wordlist.txt b/wordlist.txt index 71349ab7..37a5f915 100644 --- a/wordlist.txt +++ b/wordlist.txt @@ -332,4 +332,5 @@ SSDF SLSA pids Kata -rootfs \ No newline at end of file +rootfs +NCSC From 493a4bc972223f1556fb8c1906df8befda02e20b Mon Sep 17 00:00:00 2001 From: Dickson Date: Fri, 20 Mar 2026 23:57:22 -0400 Subject: [PATCH 04/10] Tighten browser hardening guide --- .../endpoint-security/web-browser-hardening.mdx | 16 ---------------- 1 file changed, 16 deletions(-) diff --git a/docs/pages/guides/endpoint-security/web-browser-hardening.mdx b/docs/pages/guides/endpoint-security/web-browser-hardening.mdx index 41b0a7dd..289e7390 100644 --- a/docs/pages/guides/endpoint-security/web-browser-hardening.mdx +++ b/docs/pages/guides/endpoint-security/web-browser-hardening.mdx @@ -30,9 +30,6 @@ For most Web3 teams, browser hardening is less about obscure settings and more a practical baseline is to separate wallet activity from normal browsing, minimize extension risk, keep site permissions tight, and make origin-checking part of the operating procedure before you connect a wallet or approve a request. -This page focuses on desktop browser use for Web3 work. It complements endpoint hardening, account security, and wallet -security, but it does not replace them. - ## For Individuals These steps apply to anyone using a browser to access dapps, exchanges, admin consoles, registrars, dashboards, or @@ -117,19 +114,6 @@ Focus on the settings that meaningfully reduce attack surface: - **Authentication:** use passkeys or hardware security keys for email, SSO, source control, cloud, and other accounts that can be used to pivot into Web3 operations -## For Team Members - -These guidelines apply to staff working in a shared organizational environment. - -Team members should: - -- Follow the approved browser and profile model for wallet work instead of improvising per person -- Keep personal browsing, work browsing, and wallet operations separate -- Report unexpected wallet prompts, extension changes, browser warnings, or redirected login flows -- Avoid syncing privileged profiles to unmanaged devices without explicit approval -- Keep browser protections enabled and do not bypass warnings just to complete a task faster -- Escalate suspicious domains, signing prompts, or new dapps before using them with a work wallet - ## For Admins These settings and practices apply to administrators managing browsers for engineers, operators, finance, treasury, or From c9e55b58a72b08b55614ef9b87799f8e846f95d0 Mon Sep 17 00:00:00 2001 From: Dickson Date: Sat, 21 Mar 2026 00:28:56 -0400 Subject: [PATCH 05/10] Shorten browser hardening metadata --- docs/pages/guides/endpoint-security/web-browser-hardening.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/pages/guides/endpoint-security/web-browser-hardening.mdx b/docs/pages/guides/endpoint-security/web-browser-hardening.mdx index 289e7390..d3d92d16 100644 --- a/docs/pages/guides/endpoint-security/web-browser-hardening.mdx +++ b/docs/pages/guides/endpoint-security/web-browser-hardening.mdx @@ -1,6 +1,6 @@ --- title: "Web Browser Hardening for Web3 | Security Alliance" -description: "Harden browsers for Web3 work with dedicated wallet profiles, minimal extensions, stricter permissions, limited sync, and safer signing habits." +description: "Reduce browser risk in Web3 with cleaner profiles, fewer extensions, and safer signing habits." tags: - Engineer/Developer - Security Specialist From 19b8d42f437c2c0089cdef27b00dac336fb5170a Mon Sep 17 00:00:00 2001 From: Dickson Date: Sun, 15 Mar 2026 22:43:43 -0400 Subject: [PATCH 06/10] Add web browser hardening guide for Web3 --- docs/pages/guides/endpoint-security/index.mdx | 1 + .../web-browser-hardening.mdx | 206 ++++++++++++++++++ vocs.config.tsx | 1 + 3 files changed, 208 insertions(+) create mode 100644 docs/pages/guides/endpoint-security/web-browser-hardening.mdx diff --git a/docs/pages/guides/endpoint-security/index.mdx b/docs/pages/guides/endpoint-security/index.mdx index f9f5eae7..bd7426e2 100644 --- a/docs/pages/guides/endpoint-security/index.mdx +++ b/docs/pages/guides/endpoint-security/index.mdx @@ -11,4 +11,5 @@ title: "Endpoint Security" ## Pages +- [Web Browser Hardening for Web3](/guides/endpoint-security/web-browser-hardening) - [Zoom Hardening Guide](/guides/endpoint-security/zoom-hardening) diff --git a/docs/pages/guides/endpoint-security/web-browser-hardening.mdx b/docs/pages/guides/endpoint-security/web-browser-hardening.mdx new file mode 100644 index 00000000..e3bc5806 --- /dev/null +++ b/docs/pages/guides/endpoint-security/web-browser-hardening.mdx @@ -0,0 +1,206 @@ +--- +title: "Web Browser Hardening for Web3 | Security Alliance" +description: "Harden browsers for Web3 work with dedicated wallet profiles, minimal extensions, stricter permissions, limited sync, and safer signing habits." +tags: + - Engineer/Developer + - Security Specialist +contributors: + - role: wrote + users: [dickson] +--- + +import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } from '../../../../components' + + + + +# Web Browser Hardening for Web3 + + + + +## Summary + +> 🔑 **Key Takeaway for Web Browser Hardening:** Treat the browser as part of your signing environment. Use a +> dedicated wallet profile for Web3 activity, keep it almost extension-free, leave phishing protections and updates +> enabled, keep sync limited or off for privileged work, and verify every connect, sign, and approval prompt before +> accepting it. + +For most Web3 teams, browser hardening is less about obscure settings and more about reducing accidental exposure. The +practical baseline is to separate wallet activity from normal browsing, minimize extension risk, keep site permissions +tight, and make origin-checking part of the operating procedure before you connect a wallet or approve a request. + +This page focuses on desktop browser use for Web3 work. It complements endpoint hardening, account security, and wallet +security, but it does not replace them. + +--- + +## For Individuals + +These steps apply to anyone using a browser to access dapps, exchanges, admin consoles, registrars, dashboards, or +wallet extensions. + +### Setup Checklist + +- [ ] Create a dedicated **Wallet / Signing** browser profile for Web3 work +- [ ] For admins, deployers, finance, and treasury roles, use a separate browser in addition to a separate profile if + that is operationally realistic +- [ ] Install only the extensions you actually need in the wallet profile, ideally one wallet extension plus a required + password manager +- [ ] Keep browser phishing and deceptive-site protections enabled +- [ ] Keep secure-connection defaults enabled and avoid downgrading to insecure sites +- [ ] Block notifications, pop-ups, redirects, camera, microphone, and location access by default in the wallet + profile +- [ ] Disable or avoid WebUSB and WebHID access in non-signing profiles unless there is a specific operational need +- [ ] Turn on prompts for download location and avoid automatic file opening +- [ ] Keep the wallet profile unsynced by default unless you have a clear reason to sync it +- [ ] Use stricter cookie and tracking settings so low-trust sites keep less persistent state in your browser +- [ ] Use a password manager, passkeys, or hardware-backed authentication for browser-based accounts +- [ ] Bookmark trusted dapps and admin portals instead of following wallet-related links from chat, email, or ads +- [ ] Review connected sites and token approvals regularly +- [ ] Never store seed phrases, recovery phrases, or private keys in browser password managers or cloud notes + +### Recommended Browser Operating Model + +Use at least two separate contexts: + +- **General profile:** email, chat, docs, research, social media, and routine browsing +- **Wallet / Signing profile:** wallet connections, signing flows, sensitive dashboards, registrars, exchanges, and + admin actions + +This separation reduces session reuse, extension overlap, and the chance that a random page can interact with the same +browser context you use for wallet operations. It is useful workflow separation, not a hard security boundary. Anyone +with access to your unlocked device can still access your browser profiles. + +For higher-risk roles, using a separate browser on top of a separate profile is reasonable defense in depth. Treat that +as an operational safeguard, not as proof of strong isolation. + +### Extension Discipline + +Extensions should be treated as privileged code. + +- Keep the wallet profile to the minimum extension set +- Prefer one primary wallet extension per profile to reduce provider confusion and connection issues +- If the browser or another extension offers a built-in wallet/provider you do not use, disable it in the wallet + profile +- Restrict extension site access where the browser supports it +- Install extensions only from official stores or the wallet vendor's documented source +- Remove unused extensions promptly instead of leaving them installed "just in case" +- Audit extension permissions on a regular cadence instead of assuming an old extension is still safe + +If a site asks you to install a new helper extension, disable browser protections, or re-enter wallet recovery +material, stop and verify the workflow out of band. + +### Daily Web3 Rules + +Make these checks part of your normal process: + +- Navigate to important dapps, exchanges, and admin portals through saved bookmarks or a trusted internal directory +- Before you connect a wallet, confirm the exact domain, requested account, and requested network +- Treat every signature and approval as a high-risk action, even if it is presented as a login or verification step +- Reject prompts you do not understand, especially blind signing requests, unexpected approvals, or urgent "fix your + wallet" messages +- Disconnect sites you no longer use and review token allowances on a regular cadence +- Keep wallet actions out of the general browsing profile, even for "quick" checks + +### Browser Settings That Matter + +Focus on the settings that meaningfully reduce attack surface: + +- **Anti-phishing and reputation protections:** leave them on and treat warnings as blocking signals +- **Downloads:** prompt for save location and do not auto-open files +- **Hardware wallet transports:** keep WebUSB and WebHID access tightly scoped and do not leave broad hardware access + enabled in profiles that are not used for signing +- **Notifications and pop-ups:** block by default, then add narrow exceptions only for sites you trust +- **Clipboard permissions:** avoid granting clipboard access broadly; treat it as sensitive +- **Cookies and tracking:** use stricter defaults so suspicious sites keep less persistent browser state +- **Updates:** let the browser auto-update and restart promptly when updates are pending +- **Sync:** keep privileged profiles unsynced unless your risk model explicitly allows it +- **Authentication:** use passkeys or hardware security keys for email, SSO, source control, cloud, and other accounts + that can be used to pivot into Web3 operations + +--- + +## For Team Members + +These guidelines apply to staff working in a shared organizational environment. + +Team members should: + +- Follow the approved browser and profile model for wallet work instead of improvising per person +- Keep personal browsing, work browsing, and wallet operations separate +- Report unexpected wallet prompts, extension changes, browser warnings, or redirected login flows +- Avoid syncing privileged profiles to unmanaged devices without explicit approval +- Keep browser protections enabled and do not bypass warnings just to complete a task faster +- Escalate suspicious domains, signing prompts, or new dapps before using them with a work wallet + +--- + +## For Admins + +These settings and practices apply to administrators managing browsers for engineers, operators, finance, treasury, or +other privileged users. + +### Managed Browser Baseline + +- [ ] Standardize a supported browser baseline for wallet-related work and keep users on stable channels +- [ ] Require a dedicated wallet profile for privileged workflows +- [ ] For the highest-risk roles, consider a separate dedicated browser in addition to the dedicated profile +- [ ] Default-deny browser extensions and allowlist only approved wallet and password manager extensions +- [ ] Keep browser auto-updates enabled and avoid freezing users on old versions +- [ ] Enforce phishing and deceptive-site protections and decide whether users may bypass warnings +- [ ] Restrict or disable browser sync for privileged profiles, especially on unmanaged devices +- [ ] Set conservative defaults for site permissions, downloads, notifications, pop-ups, redirects, WebUSB, and + WebHID +- [ ] Publish an approved list of high-value dapps, exchanges, admin portals, and registrars for bookmark-based access +- [ ] Require phishing-resistant MFA for the accounts that guard Web3 operations, including email, SSO, code hosting, + cloud, and registrar access +- [ ] Review connected sites, extension inventory, and exceptions during periodic access reviews + +### Admin Notes + +- A dedicated browser is helpful, but it is not a substitute for device hardening, endpoint management, or hardware + wallets +- Document which roles are allowed to sync browser data and under what conditions +- Keep exception handling narrow and explicit; do not let a "temporary" site permission or extension become permanent +- If a team depends on a small set of critical dapps, internal guidance should define the approved domains and expected + connect/sign flow for each one + +--- + +## Web3-Specific Operational Rules + +Browser hardening matters in Web3 because the browser is often the access path to a wallet, not just a place to read +web pages. + +Use these operating rules consistently: + +1. Connect wallets only from the dedicated wallet profile. +2. Verify the origin before connect, sign, approve, or switch networks. +3. Prefer one primary wallet extension per profile. +4. Do not keep stale connected-site sessions around indefinitely. +5. Review token approvals and revoke ones you no longer need. +6. Do not store seed phrases or private keys in browser-based secret storage. +7. Treat "urgent" dapp prompts, fake support chats, and recovery requests as likely phishing attempts. +8. If a prompt is confusing, stop and verify with another team member before signing. + +--- + +## Related Guides + +- [GitHub Security](/guides/account-management/github) +- [Understanding Threat Vectors](/awareness/understanding-threat-vectors) +- [Signing and Verification](/wallet-security/signing-and-verification/signing-verification) +- [Verifying Standard Transactions](/wallet-security/signing-and-verification/verifying-standard-transactions) + +## Further Reading + +- [NIST SP 800-63B: Digital Identity Guidelines](https://pages.nist.gov/800-63-4/sp800-63b.html) +- [W3C WebAuthn Level 3](https://www.w3.org/TR/webauthn-3/) +- [NCSC: Managing Web Browser Security](https://www.ncsc.gov.uk/collection/device-security-guidance/policies-and-settings/managing-web-browser-security) +- [MetaMask: What Is a Secret Recovery Phrase, and How to Secure Your Wallet](https://support.metamask.io/start/what-is-a-secret-recovery-phrase-and-how-to-keep-your-crypto-wallet-secure/) + +--- + + + diff --git a/vocs.config.tsx b/vocs.config.tsx index 8f50b117..3e8c33d7 100644 --- a/vocs.config.tsx +++ b/vocs.config.tsx @@ -551,6 +551,7 @@ const config = { text: 'Endpoint Security', collapsed: true, items: [ + { text: 'Web Browser Hardening for Web3', link: '/guides/endpoint-security/web-browser-hardening' }, { text: 'Zoom Hardening', link: '/guides/endpoint-security/zoom-hardening' }, ] }, From a63a346aed048d43191b8e80b7e8a95d80bd5513 Mon Sep 17 00:00:00 2001 From: Dickson Date: Fri, 20 Mar 2026 23:12:20 -0400 Subject: [PATCH 07/10] Remove decorative separators from browser hardening guide --- .../endpoint-security/web-browser-hardening.mdx | 15 --------------- 1 file changed, 15 deletions(-) diff --git a/docs/pages/guides/endpoint-security/web-browser-hardening.mdx b/docs/pages/guides/endpoint-security/web-browser-hardening.mdx index e3bc5806..95fb9565 100644 --- a/docs/pages/guides/endpoint-security/web-browser-hardening.mdx +++ b/docs/pages/guides/endpoint-security/web-browser-hardening.mdx @@ -32,9 +32,6 @@ tight, and make origin-checking part of the operating procedure before you conne This page focuses on desktop browser use for Web3 work. It complements endpoint hardening, account security, and wallet security, but it does not replace them. - ---- - ## For Individuals These steps apply to anyone using a browser to access dapps, exchanges, admin consoles, registrars, dashboards, or @@ -133,9 +130,6 @@ Team members should: - Avoid syncing privileged profiles to unmanaged devices without explicit approval - Keep browser protections enabled and do not bypass warnings just to complete a task faster - Escalate suspicious domains, signing prompts, or new dapps before using them with a work wallet - ---- - ## For Admins These settings and practices apply to administrators managing browsers for engineers, operators, finance, treasury, or @@ -165,9 +159,6 @@ other privileged users. - Keep exception handling narrow and explicit; do not let a "temporary" site permission or extension become permanent - If a team depends on a small set of critical dapps, internal guidance should define the approved domains and expected connect/sign flow for each one - ---- - ## Web3-Specific Operational Rules Browser hardening matters in Web3 because the browser is often the access path to a wallet, not just a place to read @@ -183,9 +174,6 @@ Use these operating rules consistently: 6. Do not store seed phrases or private keys in browser-based secret storage. 7. Treat "urgent" dapp prompts, fake support chats, and recovery requests as likely phishing attempts. 8. If a prompt is confusing, stop and verify with another team member before signing. - ---- - ## Related Guides - [GitHub Security](/guides/account-management/github) @@ -199,8 +187,5 @@ Use these operating rules consistently: - [W3C WebAuthn Level 3](https://www.w3.org/TR/webauthn-3/) - [NCSC: Managing Web Browser Security](https://www.ncsc.gov.uk/collection/device-security-guidance/policies-and-settings/managing-web-browser-security) - [MetaMask: What Is a Secret Recovery Phrase, and How to Secure Your Wallet](https://support.metamask.io/start/what-is-a-secret-recovery-phrase-and-how-to-keep-your-crypto-wallet-secure/) - ---- - From d8f8835287ec7890dd5c8eedf788627334738c50 Mon Sep 17 00:00:00 2001 From: Dickson Date: Fri, 20 Mar 2026 23:29:35 -0400 Subject: [PATCH 08/10] Fix lint in browser hardening guide --- .../guides/endpoint-security/web-browser-hardening.mdx | 7 +++++-- wordlist.txt | 1 + 2 files changed, 6 insertions(+), 2 deletions(-) diff --git a/docs/pages/guides/endpoint-security/web-browser-hardening.mdx b/docs/pages/guides/endpoint-security/web-browser-hardening.mdx index 95fb9565..41b0a7dd 100644 --- a/docs/pages/guides/endpoint-security/web-browser-hardening.mdx +++ b/docs/pages/guides/endpoint-security/web-browser-hardening.mdx @@ -32,6 +32,7 @@ tight, and make origin-checking part of the operating procedure before you conne This page focuses on desktop browser use for Web3 work. It complements endpoint hardening, account security, and wallet security, but it does not replace them. + ## For Individuals These steps apply to anyone using a browser to access dapps, exchanges, admin consoles, registrars, dashboards, or @@ -116,8 +117,6 @@ Focus on the settings that meaningfully reduce attack surface: - **Authentication:** use passkeys or hardware security keys for email, SSO, source control, cloud, and other accounts that can be used to pivot into Web3 operations ---- - ## For Team Members These guidelines apply to staff working in a shared organizational environment. @@ -130,6 +129,7 @@ Team members should: - Avoid syncing privileged profiles to unmanaged devices without explicit approval - Keep browser protections enabled and do not bypass warnings just to complete a task faster - Escalate suspicious domains, signing prompts, or new dapps before using them with a work wallet + ## For Admins These settings and practices apply to administrators managing browsers for engineers, operators, finance, treasury, or @@ -159,6 +159,7 @@ other privileged users. - Keep exception handling narrow and explicit; do not let a "temporary" site permission or extension become permanent - If a team depends on a small set of critical dapps, internal guidance should define the approved domains and expected connect/sign flow for each one + ## Web3-Specific Operational Rules Browser hardening matters in Web3 because the browser is often the access path to a wallet, not just a place to read @@ -174,6 +175,7 @@ Use these operating rules consistently: 6. Do not store seed phrases or private keys in browser-based secret storage. 7. Treat "urgent" dapp prompts, fake support chats, and recovery requests as likely phishing attempts. 8. If a prompt is confusing, stop and verify with another team member before signing. + ## Related Guides - [GitHub Security](/guides/account-management/github) @@ -187,5 +189,6 @@ Use these operating rules consistently: - [W3C WebAuthn Level 3](https://www.w3.org/TR/webauthn-3/) - [NCSC: Managing Web Browser Security](https://www.ncsc.gov.uk/collection/device-security-guidance/policies-and-settings/managing-web-browser-security) - [MetaMask: What Is a Secret Recovery Phrase, and How to Secure Your Wallet](https://support.metamask.io/start/what-is-a-secret-recovery-phrase-and-how-to-keep-your-crypto-wallet-secure/) + diff --git a/wordlist.txt b/wordlist.txt index be285213..59950331 100644 --- a/wordlist.txt +++ b/wordlist.txt @@ -337,3 +337,4 @@ rootfs GitHub GitLab GoDaddy +NCSC From 43664dd3b02c0187a113496ddfc456a60c6f3ecc Mon Sep 17 00:00:00 2001 From: Dickson Date: Fri, 20 Mar 2026 23:57:22 -0400 Subject: [PATCH 09/10] Tighten browser hardening guide --- .../endpoint-security/web-browser-hardening.mdx | 16 ---------------- 1 file changed, 16 deletions(-) diff --git a/docs/pages/guides/endpoint-security/web-browser-hardening.mdx b/docs/pages/guides/endpoint-security/web-browser-hardening.mdx index 41b0a7dd..289e7390 100644 --- a/docs/pages/guides/endpoint-security/web-browser-hardening.mdx +++ b/docs/pages/guides/endpoint-security/web-browser-hardening.mdx @@ -30,9 +30,6 @@ For most Web3 teams, browser hardening is less about obscure settings and more a practical baseline is to separate wallet activity from normal browsing, minimize extension risk, keep site permissions tight, and make origin-checking part of the operating procedure before you connect a wallet or approve a request. -This page focuses on desktop browser use for Web3 work. It complements endpoint hardening, account security, and wallet -security, but it does not replace them. - ## For Individuals These steps apply to anyone using a browser to access dapps, exchanges, admin consoles, registrars, dashboards, or @@ -117,19 +114,6 @@ Focus on the settings that meaningfully reduce attack surface: - **Authentication:** use passkeys or hardware security keys for email, SSO, source control, cloud, and other accounts that can be used to pivot into Web3 operations -## For Team Members - -These guidelines apply to staff working in a shared organizational environment. - -Team members should: - -- Follow the approved browser and profile model for wallet work instead of improvising per person -- Keep personal browsing, work browsing, and wallet operations separate -- Report unexpected wallet prompts, extension changes, browser warnings, or redirected login flows -- Avoid syncing privileged profiles to unmanaged devices without explicit approval -- Keep browser protections enabled and do not bypass warnings just to complete a task faster -- Escalate suspicious domains, signing prompts, or new dapps before using them with a work wallet - ## For Admins These settings and practices apply to administrators managing browsers for engineers, operators, finance, treasury, or From 3a1474654dc3bee97891119d7d834f4e33b40575 Mon Sep 17 00:00:00 2001 From: Dickson Date: Sat, 21 Mar 2026 00:28:56 -0400 Subject: [PATCH 10/10] Shorten browser hardening metadata --- docs/pages/guides/endpoint-security/web-browser-hardening.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/pages/guides/endpoint-security/web-browser-hardening.mdx b/docs/pages/guides/endpoint-security/web-browser-hardening.mdx index 289e7390..d3d92d16 100644 --- a/docs/pages/guides/endpoint-security/web-browser-hardening.mdx +++ b/docs/pages/guides/endpoint-security/web-browser-hardening.mdx @@ -1,6 +1,6 @@ --- title: "Web Browser Hardening for Web3 | Security Alliance" -description: "Harden browsers for Web3 work with dedicated wallet profiles, minimal extensions, stricter permissions, limited sync, and safer signing habits." +description: "Reduce browser risk in Web3 with cleaner profiles, fewer extensions, and safer signing habits." tags: - Engineer/Developer - Security Specialist