Password Protect a Static Website Safely

Password Protect a Static Website Without False Confidence

Password-protecting a static website requires something outside HTML to decide who receives its files. Yet many tutorials use a JavaScript password form to hide the page and call it done. The page looks locked, but its contents remain public.

The right method depends on the content and cost of a leak. A launch teaser differs from a financial dashboard or client data room. TL;DR: Real protection checks access before sending files; use a host, identity provider, or protected publishing service suited to the risk.

• Why client-side gates provide weak static site password protection
• When host-level authentication or an identity provider fits
• When a protected Revdoku review link is the simpler answer
• How to test whether your files are truly behind the gate

What Static Site Password Protection Actually Protects

A static site contains HTML, CSS, JavaScript, images, and PDFs. It may lack an application server for authentication. Static describes the build, not how requests are served. A web server, edge network, or publishing service can reject unauthorized requests before returning files.

Protection goal	Suitable control	Typical use
Discourage casual early viewing	Client-side prompt or obscure preview URL	Low-risk launch teaser
Require a shared secret before files load	Host or edge password gate	Staging site or short review
Identify each visitor	Email verification or individual account	Proposal, deck, or client deliverable
Apply company identity policies	SSO or identity-aware proxy	Internal tools and employee portals
Restrict highly sensitive records	Full application authorization	Health, financial, or regulated data

Access control must cover every protected asset, including direct PDF, image, JavaScript, and download URLs. It also fails closed. OWASP recommends denying access by default and checking permission on every request.

A password gate controls access to a protected website. It cannot stop authorized visitors from taking screenshots, saving files, or forwarding information. When that matters, add contracts, watermarks, individual identity, or a controlled document system.

Why Client-Side-Only Static Site Authentication Is Weak

Tutorials often store a password, hash, or success condition in JavaScript. The browser downloads it before deciding whether to reveal the page.

Visitors can inspect source, disable the script, request protected assets directly, or alter page state in developer tools.

Failure paths include:

• The password may appear as plain text in the JavaScript bundle.
• A bundled hash can be copied and guessed offline without rate limits.
• The downloaded response may already contain hidden HTML.
• PDFs, images, and JSON may remain directly accessible.
• Search engines or link scanners may bypass the form.

MITRE classifies this design problem as CWE-602: Client-Side Enforcement of Server-Side Security. Its advice is direct: security checks performed by the client must also be enforced by the server.

One exception exists. You can pre-encrypt content, then decrypt it in the browser with a key never shipped with the site. That can preserve confidentiality but complicates key distribution, caching, recovery, accessibility, and updates. You are then building an authentication and encryption product. For most client work, server-side or edge gates are safer and cheaper.

Example: A founder may use a JavaScript prompt to discourage accidental viewing of a harmless launch announcement. I would not use it for unreleased pricing, a proposal, customer information, or source files.

Five Ways to Password Protect a Static Website

Static site authentication options vary in enforcement, visitor friction, and owner data.

Approach	Where access is checked	Visitor identity	Best fit	Main limitation
JavaScript prompt	Inside the downloaded page	Usually none	Low-risk deterrence	Files are already public
HTTP Basic Auth	Web server or reverse proxy	Shared or named credentials	Small self-hosted previews	Plain browser prompt and manual account work
Hosting-platform protection	Hosting provider edge	Shared password or platform account	Existing preview deployments	Features and scope depend on the plan
Identity-aware proxy	Edge proxy connected to an IdP	Individual identity	Internal tools and sensitive demos	More policy and account setup
Revdoku protected publishing	Publishing service gate	Password access or verified email	Client-facing files, demos, and presentations	Not a substitute for custom application authorization

Several mainstream hosts control access before serving files. Netlify documents shared-password and team-login protection, while Vercel provides deployment authentication and plan-dependent password protection. Eligible GitHub Enterprise Cloud organizations can publish private Pages sites, but visitors need repository read access, often awkward for clients. GitHub explains those limits in its Pages access-control documentation.

Balance visitor experience with technical strength. Clients should not need developer accounts to read proposals.

When Host-Level Static Site Password Protection Is the Right Choice

Host-level protection works when the deployment platform offers suitable access controls. Authentication occurs before the origin returns index.html or related assets. This preserves the build, domain, deployment pipeline, and preview workflow.

1. Define protected scope. Cover production, preview, and old deployment URLs, plus assets and download paths containing private material.

2. Select the access model. Use a shared password for a short, low-risk review. Use named users, one-time codes, SSO, or an identity-aware proxy for revocation and attribution.

3. Require HTTPS: HTTP Basic credentials are Base64-encoded, not encrypted. MDN warns that Basic authentication needs HTTPS/TLS to prevent interception.

4. Test externally. In a private window, request the home page, a nested route, a PDF, and a copied asset URL.

5. Plan for automation. Monitoring, screenshots, and end-to-end tests may require narrowly scoped service or bypass credentials.

Agency example: An agency using a Netlify or Vercel preview pipeline can enable deployment protection for client acceptance. This keeps code review and preview deployment together.

Internal example: A finance dashboard should use an access proxy with individual identity, not a password sent through chat. Cloudflare Access, for example, acts as an identity-aware proxy and checks protected web requests against access policies.

When a Private Client Link with Revdoku Is Enough

Sometimes you do not need a private application. You need a private link for a proposal, PDF, presentation, report, or static demo, plus open tracking, responses, and later replacement. Revdoku serves that workflow.

1. Create or open a private Revdoku bucket.
2. Add a PDF or static-site folder.
3. Publish a public, password-protected, or verified-email link.
4. Enable notifications for successful protected entry.
5. Review activity and update the bucket as work changes.

According to the Revdoku product documentation, buckets store static assets and versions, protected websites use a separate password gate, and republishing the same bucket retains its URL. The current product page describes per-visitor records for pages viewed, links clicked, and files downloaded. It also supports password access, one-time-code email access, email or domain allowlists, and visitor feedback.

Freelancer example: Send a password-protected proposal on Monday. After the client enters and reads the pricing page, the notification gives you a better follow-up reason than a blind Tuesday email.

Consultant example: Publish a weekly research report at one link and replace its files each Friday. An AI agent, API, or CLI can automate updates but is unnecessary for the initial drag-and-drop workflow.

Choosing the Right Static Site Authentication for Each Project

My rule: use the lightest control that withstands the likely threat. Do not build an account system for a disposable mockup. Do not send regulated records through a shared review password merely for convenience.

• Choose a client-side prompt only when disclosure causes little or no harm and the gate is clearly a deterrent.
• Choose host-level protection when you manage the deployment and need one gate for all site files.
• Choose verified email or individual accounts to identify entrants, revoke individuals, or separate client activity.
• Choose an identity-aware proxy for company SSO, group policies, device rules, or employee offboarding.
• Choose a protected Revdoku link for a client-facing document, deck, demo, report, or static bundle when review activity matters.
• Choose a custom authenticated application for user-specific data or permissions.

Product studio example: An agency sharing the same prototype with five client stakeholders could use Revdoku Verified Email. This yields clearer visitor records than a shared password while retaining a normal browser-link experience.

A draft homepage, sales forecast, and database export can all be static yet carry different risks. Static describes the delivery format, not the sensitivity.

Static Site Password Protection Best Practices

A few operating habits prevent most embarrassing leaks. Treat the gate as part of publishing, not an afterthought once the link is sent.

Item	What to Check	Why It Matters
Password length	Use a unique passphrase of at least 15 characters	NIST sets 15 characters as the minimum for single-factor passwords
Transport	Confirm every protected URL uses HTTPS	A password cannot protect traffic sent in clear text
Asset coverage	Test HTML, PDFs, images, JSON, and downloads directly	Protecting only the home page leaves side doors open
Client separation	Use a different secret or gate for each project	One forwarded password should not expose other work
Revocation	Know how to change access or take the link offline	Client teams and project scopes change
Logged-out test	Retest after every deployment or configuration edit	Protection can disappear through a scope mistake
Data collection	Record only the visitor data needed for follow-up	Access analytics create their own privacy duties

NIST SP 800-63B requires at least 15 characters for a single-factor password and advises against arbitrary periodic changes. Change a shared password after possible forwarding, a stakeholder’s departure, or the review’s end.

Avoid home-built authentication backends. The 2026 Verizon DBIR reports that vulnerability exploitation initiated 31% of breaches. Custom server code requires patching, monitoring, rate limiting, and review. A maintained host or publishing gate reduces that burden.

Static Site Password Protection Pitfalls

Most failures occur around the gate.

• Protecting / while leaving /files/proposal.pdf public
• Sending a broad group the password with the link
• Treating an unlisted or obscure URL as authentication
• Using robots.txt as access control when compliant crawlers may only avoid indexing
• Leaving old previews online after review
• Collecting emails without identifying the recipient

Final Thoughts

Proper static site password protection blocks files before they reach the browser. A JavaScript prompt may deter accidental visitors but cannot provide real access control.

• Use host or edge protection for deployments.
• Use individual identity for sensitive systems.
• Use Revdoku for private client links with password protection, tracking, feedback, and same-URL updates.

Test direct assets while logged out. This five-minute check catches the most common mistake: a locked-looking home page fronting public files. The best method matches the risk, covers every relevant request, and stays simple enough to use correctly.

Ask ChatGPT to check the access mode

Before sharing, ChatGPT can ask Revdoku what access mode is active for the bucket. Use this to confirm whether the link is public, password protected, or email gated.

Start publishing for free

Connect this AI to Revdoku so it can store files, create, update, and publish websites for me. Read and follow https://revdoku.com/prompt.md. For ChatGPT, Claude, or another cloud AI, connect https://app.revdoku.com/mcp and complete Revdoku OAuth. For a local agent, use Revdoku's browser device sign-in and complete the connection in Revdoku. Never ask me for a password or API key in chat. When Revdoku tools are connected, verify the connection, tell me you’re ready, and ask what I want to publish.

Copy Prompt

or

Create Free Account