Skip to content
    • Pricing
    • Developers
    Back to Blog
    security

    Reserved Alias Protection: Engineering Trust and Brand Safety

    2026-03-08·4 min read·Plung Team

    On this page

    • The Problem: The Hidden Risks of Custom Aliases
    • Our Solution: Three-Tier Validation
    • Tier 1: Dynamic Admin Overrides
    • Tier 2: Static Reserved Lists
    • Tier 3: Malicious Pattern Detection
    • Enhancing the Developer Experience
    • Building a Safer Web, Together

    At Plung, our mission is to provide the fastest, most private way to shorten URLs. But speed and privacy must never come at the expense of safety. Today, we are excited to announce a significant enhancement to our platform: Reserved Alias Protection.

    The Problem: The Hidden Risks of Custom Aliases

    Custom aliases are a powerful feature, allowing users to create memorable and branded links. However, they also present unique security challenges. Without proper protection, malicious actors can exploit custom aliases for:

    1. Phishing and Impersonation: Creating links like plung.co/login, plung.co/verify-account, or plung.co/google-support to trick users into revealing sensitive information.
    2. Brand Hijacking: Squatting on well-known brand names or trademarks to redirect users to unauthorized or harmful content.
    3. System Route Conflicts: Accidentally or intentionally overlapping with internal platform routes (e.g., /api, /console, /admin), potentially causing service disruptions.

    Our Solution: Three-Tier Validation

    To address these risks, we have implemented a robust, three-tiered validation system that operates in real-time during every shortening request.

    Tier 1: Dynamic Admin Overrides

    The highest priority in our system is the Admin Override layer. This allows our team to manually allow or block specific aliases with high precision. For example, if a strategic partner needs a specific alias that is normally reserved, we can create an "Allow" override. Conversely, if we detect a new phishing pattern, we can instantly "Block" it across the entire platform.

    Tier 2: Static Reserved Lists

    We maintain a comprehensive, curated list of reserved aliases that are prohibited by default. This list includes:

    • System Routes: Internal paths like api, console, admin, login, and logout.
    • Brand Names: Global technology, finance, and retail brands.
    • Government and Institutional Entities: Trusted organizations that are frequently targeted by impersonation.

    Tier 3: Malicious Pattern Detection

    Beyond static lists, we use advanced pattern matching to catch variants of reserved aliases. This tier identifies attempts to circumvent protections using:

    • Homoglyph Attacks: Using similar-looking characters from different alphabets (e.g., replacing 'o' with '0').
    • Suffix/Prefix Variations: Catching aliases like login-now or official-support.
    • Known Phishing Keywords: Prohibiting terms commonly used in credential harvesting campaigns.

    Enhancing the Developer Experience

    We believe that security should be transparent. Our updated API documentation now includes detailed information about reserved alias validation. When a developer or user attempts to use a reserved alias, the API returns a clear, actionable error message:

    {
      "statusCode": 400,
      "timestamp": "2026-03-08T14:40:00.000Z",
      "path": "/v2/shorten",
      "method": "POST",
      "message": "This alias is reserved and cannot be used"
    }
    

    On our frontend, these errors are now displayed directly under the "Custom Alias" input field, providing immediate feedback and a smoother user experience.

    Building a Safer Web, Together

    Reserved Alias Protection is more than just a security feature; it is a commitment to the trust our users place in Plung. By preventing the creation of deceptive links, we are not only protecting our platform but also contributing to a safer internet for everyone.

    This feature is available immediately to all users. We will continue to refine our validation patterns and monitor the threat landscape to ensure Plung remains the most trusted name in URL shortening.

    Share:

    Share Article

    Written by

    Plung Team

    ← PreviousPlung Developer Platform Is LiveNext →From URL Shortener to Platform: How We Built Secure APIs, Quotas, and Safety Into Plung

    On this page

    • The Problem: The Hidden Risks of Custom Aliases
    • Our Solution: Three-Tier Validation
    • Tier 1: Dynamic Admin Overrides
    • Tier 2: Static Reserved Lists
    • Tier 3: Malicious Pattern Detection
    • Enhancing the Developer Experience
    • Building a Safer Web, Together

    Related Articles

    H
    security

    How We Keep Plung Links Safe Without Tracking You

    Spam detection, phishing prevention, and abuse mitigation — all without collecting personal data. Here is how we engineered trust into a zero-account platform.

    2026-02-23·5 min read
    P
    announcement

    Plung API Notice: Authorization Bearer Tokens Are Now Required for Current API Authentication

    Current authenticated Plung API requests must send API keys in the Authorization header using the Bearer scheme. This notice explains the change, the impact, and the required migration steps.

    2026-03-21·4 min read
    A
    product

    Analytics You Can Trust: How Plung Now Captures Real Clicks Across Devices, Countries, and Redirect Paths

    Plung analytics now gives link owners cleaner click counts, more accurate country and device reporting, and a read-only analytics experience that does not inflate results.

    2026-03-13·6 min read

    Product

    • About Us
    • Blog
    • Developers

    Features

    • URL Shortening
    • Custom Aliases
    • QR Codes
    • Password Protection
    • Link Analytics
    • Link Expiration

    Legal

    • Privacy Policy
    • Cookies Policy
    • Terms of Service
    • Acceptable Use Policy

    Support

    • Contact Us
    • Report Abuse

    © 2026 Plung

    All Rights Reserved