Onetime SecretOnetime SecretBlog
Back to Blog
Engineering

Domain Strategy Reengineered: Building Verification into Our Architecture

·5 min read
Delano Delano

A recent phishing attempt exposed users to an impostor site that mirrored our interface but actually exposed secrets. While Cloudflare helped shut down this particular site, the incident highlighted a broader concern: user can struggle to distinguish legitimate from fraudulent services (see Which one of these is the real onetimesecret?).

Following our recent homepage update emphasizing regional domains, this post details how our domain structure bolsters security through clarity and consistency—a vital consideration for a service handling sensitive information.

onetimesecret.com

Our .com Domain: Separation of Concerns

Strategic Change: We've moved our apex domain (onetimesecret.com) from functioning as an alias for eu.onetimesecret.com to a completely separate codebase with static content. While standard practice for most products, this is new for our service which has maintained a functional homepage since launch over 10 years ago.

Technical Benefits:

  • Distinctive User Experience: Creates a clear visual and functional difference from impostor sites
  • Streamlined Application Codebase: Removing marketing content makes our open-source project simpler for self-hosted installations
  • Independent Release Cycles: Marketing site changes no longer require application deployments
  • SEO Protection: Consolidates domain authority to maintain search ranking visibility against sites using similar keywords and paid advertisements

Domain Strategy Evolution: Before vs. After

New Homepage New Onetime Secret marketing homepage
Our new marketing homepage at onetimesecret.com
Application Interface Onetime Secret application interface
Application interface at regional domains (e.g., eu.onetimesecret.com)

After Our Update:

  • Apex domain (onetimesecret.com) is now a separate, static marketing site with distinct visual design
  • All legitimate secret-creation services use consistent regional subdomains (e.g., nz.onetimesecret.com)
  • Clear visual distinction between marketing site and application interface
  • All official subdomains follow consistent naming patterns (docs, blog, status)

Before Our Update:

  • Our apex domain (onetimesecret.com) functioned as an alias to eu.onetimesecret.com
  • The same application codebase served both marketing and application content
  • Regional instances were available but not emphasized
  • Users had difficulty distinguishing legitimate sites from impostor sites

How This Protects Our Users

Our domain strategy creates clear verification markers to help users identify authentic Onetime Secret services:

  • Consistent Domain Pattern: All legitimate services use the *.onetimesecret.com pattern - if you see onetímesecret.org, 1timesecret.com, or similar variations, it's not our service.
  • Visual Distinction: Our marketing site now has a distinctly different appearance from our application interface - impostors typically copy just one look.
  • Regional Subdomains: Legitimate services always use regional identifiers (e.g., eu.onetimesecret.com) - phishing sites rarely implement complete regional architecture
  • Official Naming Conventions: All legitimate subdomains follow consistent patterns (docs, blog, status).

Conclusion: Engineering Security Through Domain Architecture

Our domain restructuring delivers concrete security improvements while enhancing our development workflow:

  1. Clear User Verification: Consistent domain patterns provide intuitive verification markers
  2. Infrastructure Protection: Domain separation creates technical barriers against impersonation
  3. Development Efficiency: Decoupled codebases enable independent release cycles
  4. Compliance Enhancement: Regional structure supports data sovereignty requirements

This architectural approach transforms our domain strategy from a potential security vulnerability into a defensive asset.

Our next post will provide a detailed verification guide for users to validate authentic Onetime Secret services.

Domain Strategy Diagram

Addendum: Quick Reference

The more you know™️
  • Apex domain: The "root" domain of a website (e.g., example.com without any prefixes).
  • Top-Level Domain (TLD): - the last segment of a domain name (e.g., .com, .dev, .org).
  • HSTS preload: A security feature that forces browsers to always use secure HTTPS connections. See hstspreload.org.
  • Origin separation: Technical isolation between different website domains for security purposes.
  • Cookie jars: Storage areas in browsers where websites store small bits of data.

Verifying Authentic Onetime Secret Services

Following our domain architecture update, this guide provides concrete methods to verify authentic Onetime Secret services and identify impostor sites.

Homepage Update: We're Going Regional

OnetimeSecret.com has been around for quite a while – long enough to attract several impostor sites ranging from confusingly similar to downright malicious. Thanks to our alert users and partners (like in this recent GitHub issue), we can spot and address these problems.