Restricting where a flipbook can be embedded by allowing only specific website domains.
Definition
Domain whitelisting is a security measure that restricts where a flipbook or document can be embedded by specifying a list of approved website domains. When someone places an [embed code](/glossary/embed-code) on a webpage, the viewer checks the hosting domain against the whitelist before loading. If the domain is not on the approved list, the content is blocked and the viewer does not render. This gives publishers precise control over where their content appears on the web, preventing unauthorized redistribution without affecting the embed code itself.
Why It Matters
Embed codes are easy to copy. Once your flipbook is embedded on one site, anyone can inspect the page source, grab the iframe code, and paste it on their own website. Without domain restrictions, your content could appear on competitor sites, low-quality aggregator pages, or platforms that misrepresent your brand. Domain whitelisting closes this gap by enforcing distribution boundaries at the viewer level. It protects intellectual property, preserves brand integrity, and ensures that licensed or confidential content remains within its intended context.
How It Works in FlipLink
FlipLink's [Privacy & Access Control](/features/privacy-and-access-control) settings include domain whitelisting. When configuring a publication, you enter the domains where the flipbook is allowed to be embedded — for example, your company website and a partner's site. Each time the embed loads, FlipLink checks the referring domain. If it matches an entry on the whitelist, the content renders normally. If not, the viewer displays a blocked message. You can add or remove domains at any time without regenerating or redistributing the embed code already placed on approved sites. This works alongside other access controls like [password protection](/features/password-protection) and [OTP verification](/glossary/otp).
Setup Checklist
1. **Open publication settings** — navigate to your flipbook or document in the FlipLink dashboard
2. **Go to Privacy & Access Control** — find the domain whitelisting section
3. **Add approved domains** — enter each domain where embedding is permitted (e.g., `yourcompany.com`, `partner-site.com`)
4. **Include subdomains if needed** — if your content is embedded on `docs.yourcompany.com`, add that subdomain explicitly
5. **Test the embed** — load the embed on an approved domain and on a non-approved domain to confirm the whitelist is working
6. **Update as needed** — when adding new partner sites or removing old ones, edit the whitelist without touching the embed code
When to Use It
Domain whitelisting is most valuable when your content is embedded on external websites rather than only shared via direct links. Consider enabling it when:
- You distribute content through partner or reseller websites and want to control which partners can display it
- Your publications contain proprietary information like product specifications, pricing sheets, or internal training materials
- You license content to specific clients and need to enforce where it can be viewed
- Your brand guidelines require that content only appears within approved contexts
If your flipbooks are shared exclusively via direct links (not embeds), domain whitelisting will not apply since there is no hosting domain to check. In that case, [password protection](/features/password-protection) or [link expiration](/glossary/link-expiry) may be more appropriate.
Security Considerations
Domain whitelisting operates on the HTTP `Referer` header, which the browser sends when loading the embedded iframe. While this is reliable for standard browser behavior, it has limitations. Some privacy-focused browsers or browser extensions strip or modify the `Referer` header, which could cause the whitelist to block legitimate views. To address this, publishers should combine domain whitelisting with other security layers — [password protection](/features/password-protection) for sensitive content, [OTP verification](/glossary/otp) for identity confirmation, and [analytics](/features/analytics-and-insights) to monitor where views originate. This layered approach provides defense in depth rather than relying on a single control.