Password Protect a Static Website Safely

Password Protect a Static Website Without False Confidence

To password protect a static website, something outside the HTML must decide who receives its files. Many tutorials add a JavaScript password form, hide the page behind it and call it done. The page looks locked, but its contents are still public.

The right method depends on the content and on the cost of a leak. A launch teaser is not a financial dashboard or a client data room.

In short, real protection checks access before the server sends any file. Choose a method that matches the risk. You can use the password feature of your host or an identity-aware proxy (a gate that identifies each visitor), such as Cloudflare Access. You can also use HTTP Basic Auth on your own server.

This guide covers:

• Why client-side gates (gates that run in the browser) are weak static site password protection
• The five common ways to protect a static site, and where each one checks access
• Step-by-step setup on Netlify, Vercel, Cloudflare Pages and your own server
• How to make sure that every file is behind the gate

What Static Site Password Protection Actually Protects

A static site is HTML, CSS, JavaScript, images and PDFs. Many static sites have no application server to run a login. But “static” describes how you build the site, not how the server answers requests. A web server, an edge network or a hosting platform can still refuse a request before it returns any file.

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 accounts	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. This includes direct PDF, image, JavaScript and download URLs. It must also fail closed. If the control fails, it blocks access. OWASP recommends denying access by default and validating permissions on every request.

A password gate controls who can reach the site. It cannot stop an authorized visitor from taking screenshots, saving files or forwarding information. If that is a risk, add contracts, watermarks, individual identity or a controlled document system.

Why Client-Side-Only Static Site Authentication Is Weak

Tutorials often store a password, a hash (a one-way code made from the password) or a success condition in JavaScript. The browser downloads that code before it decides whether to show the page. Usually it downloads the protected content too.

Visitors can read the source, turn off the script, request protected files directly or change the page state in developer tools. Typical failures are:

• The password appears as plain text in the JavaScript bundle.
• Anyone can copy a bundled hash and guess it offline, with no rate limit.
• The downloaded response already contains the hidden HTML.
• PDFs, images and JSON files remain directly reachable.
• Search engines and link scanners skip the form entirely.

MITRE classifies this design problem as CWE-602: Client-Side Enforcement of Server-Side Security. Its advice is direct. If the client performs a security check, the server must also enforce it.

There is one exception. You can encrypt the content before you publish it. Then the browser decrypts it with a key that is not part of the site. That can keep the content confidential, but it complicates key distribution, caching, recovery, accessibility and updates. At that point, you build an authentication and encryption product. For most client work, a server-side or edge gate is safer and cheaper.

For example, a JavaScript prompt is fine to discourage accidental views of a harmless launch announcement. Do not use it for unreleased pricing, a proposal, customer information or source files.

Five Ways to Password Protect a Static Website

Approach	Where access is checked	Visitor identity	Best fit	Main limitation
JavaScript prompt	Inside the downloaded page	Usually none	Low-risk deterrence	The files are already public
HTTP Basic Auth	Your web server or reverse proxy	Shared or named credentials	Small self-hosted previews	Plain browser prompt, manual account work
Hosting-platform protection	The host’s edge	Shared password or platform account	Sites already deployed on Netlify or Vercel	Features and scope depend on the plan
Identity-aware proxy	An edge proxy linked to an identity provider or email codes	Individual identity	Client reviews, internal tools, sensitive demos	More policy setup
Document-sharing service	The service’s viewer	Password, email or verified email	A single PDF or deck rather than a site	Built for documents, not multi-page sites

Several mainstream hosts check access before they serve files. Netlify documents shared-password and team-login protection. Vercel offers Deployment Protection with Vercel Authentication on all plans and Password Protection on paid plans. Eligible GitHub Enterprise Cloud organizations can publish private GitHub Pages sites. But visitors need read access to the repository, and this is awkward for clients (GitHub Pages visibility docs). On other GitHub plans, Pages sites are public.

Balance visitor experience with technical strength. Do not make a client get a developer account to read a proposal.

Set Up the Gate on Common Hosts

Netlify

Basic password protection for a whole site is available on Pro and Enterprise plans. It is not available on the credit-based Free and Personal plans (Netlify password protection).

1. Open the project. Go to Project configuration > General > Visitor access.
2. On current Pro plans, open Project visibility. Select Edit visibility, then Password. On Enterprise and older plans, the same section has the name Password Protection. There, select Configure Password Protection.
3. Enter a long passphrase. Save the change.
4. Choose whether to protect all deploys or only previews. If you protect all deploys, the protection covers production, Deploy Previews and branch deploys.

Netlify also supports a Basic-Auth rule in the _headers file for specific paths on Pro and Enterprise plans:

/protected/*  Basic-Auth: reviewer:long-passphrase-here

Use this rule only for low-sensitivity paths. Netlify itself warns that basic authentication does not encrypt credentials or give users a way to log out (Netlify basic authentication). How to Password Protect a Netlify Site covers the details.

Vercel

1. Open the project, then Settings > Deployment Protection.
2. Choose a method. Vercel Authentication is available on all plans. It admits logged-in Vercel users who have access and anyone that you give a Shareable Link. Password Protection is available on Pro (as a paid add-on) and Enterprise, not on Hobby (Vercel Password Protection).
3. Choose the scope. Standard Protection protects every deployment except your production domains. All Deployments protects production as well.
4. If you chose Password Protection, enter the password. Then select Save.

Make sure that you chose the correct scope. With Standard Protection, the production domain stays public. How to Password Protect a Vercel Site has the full walkthrough.

Cloudflare Pages with Cloudflare Access

Cloudflare Pages has no password field. Instead, you put Cloudflare Access in front of the project. Visitors sign in with an emailed one-time code, a company identity provider (the service that manages company sign-ins) or both.

1. In the Pages project, go to Settings > General. Select Enable access policy. This protects only preview deployments (preview deployment docs).
2. To protect the production *.pages.dev address too, edit the Access application. Follow Cloudflare’s known issues for Pages. One of the changes is to remove the wildcard from the subdomain field.
3. Turn on email codes at Zero Trust > Integrations > Identity providers > Add new identity provider > One-time PIN. Each code expires 10 minutes after the request. Cloudflare only sends a code to addresses that your policy allows (One-time PIN docs).
4. Write an Allow policy that includes the specific Emails or Emails ending in a client’s domain (Access policies).
5. For a custom domain, create a separate self-hosted application. Go to Zero Trust > Access controls > Applications > Create new application > Self-hosted and private > Add public hostname. The domain must be an active zone in your Cloudflare account (self-hosted application docs).

Then every sign-in appears in the Access authentication logs of the Zero Trust dashboard. Each entry shows the email of the user, the time and whether Cloudflare allowed access (log docs). How to Password Protect a Cloudflare Pages Site shows each screen.

Your own server with HTTP Basic Auth

On a server that you run, Nginx and Apache can require a username and password before they serve any file. With Nginx, create a password file (NGINX guide):

sudo htpasswd -c /etc/apache2/.htpasswd reviewer

Then protect the location of the site:

location / {
    auth_basic           "Client review";
    auth_basic_user_file /etc/apache2/.htpasswd;
}

Basic credentials are encoded, not encrypted. Serve the site only over TLS (the encryption behind HTTPS). MDN warns that Basic authentication is insecure without HTTPS.

When Host-Level Protection Is the Right Choice

Host-level protection works when your deployment platform offers suitable access controls. Authentication happens before the origin (the server that holds the files) returns index.html or any asset. You also keep your build, domain, deployment pipeline and previews.

1. Define the protected scope. Cover production, preview and old deployment URLs. Also cover every asset and download path that holds private material.
2. Select the access model. A shared password suits a short, low-risk review. With named users, one-time codes, SSO or an identity-aware proxy, you can remove one person and see who visited.
3. Require HTTPS. HTTP Basic credentials are only Base64-encoded.
4. Test from outside. In a private window, request the home page, a nested route, a PDF and a copied asset URL.
5. Plan for automation. Monitoring, screenshot tools and end-to-end tests can need a narrow bypass of the gate. For example, Vercel offers Protection Bypass for Automation.

For example, an agency that already deploys previews on Netlify or Vercel can turn on deployment protection for client acceptance. Code review and previews stay in one pipeline.

Another example is an internal finance dashboard. Put it behind an access proxy with individual identity, not a password sent through chat. Cloudflare Access checks each request to a protected application against your access policies.

When You Only Need to Share a Document

Sometimes you do not need a private website at all. You need a private link to a proposal, a PDF, a deck or a report. You also want a view notification and a way to replace the file later.

A document-sharing service such as Papermark or Dropbox DocSend fits that job better than a static host. With both, you can require a password or an email address before viewing. You can also turn downloads off and set an expiration date. If you replace the file, the link stays the same. Email verification is on their higher plans.

For example, a freelancer sends a password-protected proposal on Monday. If the client opens it and reads the pricing page, the freelancer has a better reason to follow up. A blind Tuesday email gives no such reason.

How to Share a Password-Protected Ebook shows the same approach for a longer document.

Choosing the Right Method for Each Project

Use the lightest control that withstands the likely threat. Do not build an account system for a disposable mockup. Also, do not send regulated records behind a shared review password for convenience.

Choose a method by the risk:

• 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 every file.
• Choose verified email or individual accounts when you need to identify visitors, remove one person or separate clients.
• Choose an identity-aware proxy for company SSO, group policies, device rules or employee offboarding.
• Choose a document-sharing service for a single document when you need page-level activity data.
• Choose a custom authenticated application for user-specific data or permissions.

For example, an agency shares one prototype with five client stakeholders. The agency can put it behind Cloudflare Access with email codes for those five addresses. The logs then show which stakeholder signed in and when. A shared password cannot show this.

A draft homepage, a sales forecast and a database export can all be static files. But they carry very different risks. “Static” describes the format, not the sensitivity.

Static Site Password Protection Best Practices

A few habits prevent most embarrassing leaks. Treat the gate as part of publishing, not as an afterthought after you send the link.

Item	What to do	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	Make sure that every protected URL uses HTTPS	A password cannot protect traffic sent in clear text
Asset coverage	Request HTML, PDFs, images, JSON and downloads directly	If you protect only the home page, side doors stay open
Client separation	Use a different secret or policy for each project	Then one forwarded password does not expose other work
Revocation	Know how to change access or take the site offline	Client teams and project scopes change
Logged-out test	Retest after every deployment or configuration change	A scope mistake can remove the protection
Data collection	Keep only the visitor data that you need	Access logs carry their own privacy duties

NIST SP 800-63B requires at least 15 characters for a password that is the single factor. It says not to force periodic changes. But it says to force a change when there is evidence of compromise. For a shared review password, this rule has a clear meaning. Change the password after possible forwarding, when a stakeholder leaves or when the review ends.

Avoid home-built authentication backends. The 2026 Verizon DBIR reports that 31% of breaches now start with software vulnerabilities. Custom server code needs patching, monitoring, rate limiting and review. With a maintained host feature or access proxy, you do not have to do that work.

Static Site Password Protection Pitfalls

Most failures happen around the gate, not in it.

• Protecting / while leaving /files/proposal.pdf public
• Choosing Vercel’s Standard Protection and assuming that it covers the production domain
• Protecting previews on Cloudflare Pages but not the pages.dev address or the custom domain
• Sending a large group the password together with the link
• Treating an unlisted or obscure URL as authentication
• Using robots.txt as access control, when it only asks compliant crawlers to stay away
• Leaving old previews online after the review ends

Real static site password protection blocks files before they reach the browser. A JavaScript prompt can deter accidental visitors, but it is not access control.

For deployments, use the protection of your host or an access proxy. For sensitive systems, use individual identity. For single documents, use a document-sharing service. Then sign out and test direct asset URLs. That five-minute test catches the most common mistake: a home page that looks locked in front of public files.

Free email addresses
for your AI agents

Each agent gets an address like myagent.x7k2@revdokumail.com. It can receive emails, send replies and store files.

• 3 free mailboxes, each with its own address
• 3,000 incoming and 500 sent emails a month
• 3 GB of storage for attachments and files
• Virus, malware, spam and prompt-injection filter
• Read and reply through API, MCP or CLI

Create free mailbox

You do not need a card.