Coder Legion - Recent posts tagged application-security

Safe Public Demo Environments for Android Apps

Thu, 08 Oct 2026 23:37:04 +0000

Offering a public demo of an Android application presents a unique architectural challenge. A demo build is exposed to strangers and needs frequent, destructive data resets, yet it must never be able to target or corrupt the real customer database by accident. Relying on a simple runtime UI flag or environment toggle inside the production codebase creates an unacceptable risk of accidental data leakage. This article examines how to build a robust isolation boundary using separate build variants, dedicated demo backends, and fail-closed identity validation.

Why a Demo Toggle Fails as an Isolation Boundary

Many development teams initially attempt to support public demonstrations by adding a toggle within the primary application and backend. The logic often checks whether a demo mode flag is active before skipping certain write operations or routing requests to mock data. This approach fails because a single code path or misconfigured deployment can easily bypass the flag. If a build script accidentally packages the production credentials or connects the demo backend to the primary database, a public reset operation can wipe out real customer records.

True isolation requires separating the trust boundary at every layer of the architecture. The application package name, the backend service instance, and the database project reference must be distinct. If any component in the chain does not match the expected demo configuration, the service should refuse to start entirely rather than attempting to recover or fallback.

Separate Android Build Variants and App Identity

The first layer of defense begins in the Android client. Using build variants allows developers to maintain different application IDs, source sets, and configuration values within the same repository. By modifying the application ID for the demo variant, the operating system treats the demo build and the production build as entirely separate apps on the test device.

android {
    defaultConfig {
        applicationId "com.example.app"
    }
    buildTypes {
        release {
            minifyEnabled true
        }
    }
    flavorDimensions "mode"
    productFlavors {
        production {
            dimension "mode"
            applicationIdSuffix ""
        }
        demo {
            dimension "mode"
            applicationIdSuffix ".demo"
        }
    }
}

This configuration ensures that installation artifacts are distinct. More importantly, keeping the choice fixed in the build artifact prevents users or automated scripts from accidentally activating a demo mode inside a production binary.

Verify Backend and Database Identity

Client-side separation alone is insufficient if the backend can connect to any database via environment variables. A dedicated demo backend must require explicit configuration flags and perform strict startup validation. During initialization, the backend should compare the database project reference derived from its active connection string against an expected demo project reference.

If the strings do not match, the application must immediately throw an unhandled exception and shut down. This fail-closed mechanism ensures that a server misconfiguration becomes immediately visible during deployment rather than remaining a latent vulnerability.

Seed and Reset Guarded Disposable Data

Public demo environments require a mechanism to restore clean state after users alter or delete records. However, this reset mechanism must be guarded against accidental execution against live systems. Implementation evidence suggests a two-step validation model for data lifecycle management:

Initial seeding should only proceed if every demo table is entirely empty. If existing records are detected, the seed routine halts.
Subsequent resets require a persisted security sentinel string to match the configured sentinel, and the database identity must be re-verified immediately before any deletion takes place.

Furthermore, developers should strip all non-essential integrations from the demo service. Production push notification credentials, third-party payment hooks, and external spreadsheet integrations should be omitted so that a compromised or heavily tested demo environment cannot trigger external side effects.

What Process-Local Locks Do Not Protect

When implementing automated reset endpoints, developers frequently reach for concurrency primitives such as a language-specific mutex to prevent overlapping reset requests. While a process-local mutex successfully serializes concurrent coroutines or threads within a single backend instance, it offers no protection in a horizontally scaled architecture. For a related implementation, see Managing Concurrent Git Commits During Automated.

If the demo backend is deployed behind a load balancer with multiple active instances, each instance maintains its own memory space and its own mutex. Two distinct server processes could execute a database reset simultaneously. Protecting a multi-instance demo environment requires database-level locking, a dedicated single-instance worker queue, or another distributed coordination mechanism. For a related implementation, see Safe Multi Environment Database Orchestration.

Release Checklist for a Public Demo

Before launching a public demo environment, verify the following architectural controls:

The demo application variant uses a distinct application ID suffix.
The backend enforces explicit demo mode flags and fails startup if the database project reference does not match.
Initial data seeding refuses to run unless all target tables are empty.
Destructive reset operations require a valid persisted sentinel check and a pre-execution database identity re-validation.
Session secrets and sentinels meet minimum length requirements.
Non-essential production integrations and credentials are completely removed from the demo service deployment.

Safely Rejecting Redirects in Cloudflare Workers

Fri, 02 Oct 2026 12:28:25 +0000

When writing a Cloudflare Worker that fetches remote assets from third party APIs or origin servers, an outbound request might return a 3xx redirect status code. Automatically following that redirect can bypass internal URL allowlists, leak authorization headers to unintended destinations, and compromise application security. Standard browser or Node.js fetch configurations do not always translate directly to edge runtimes. If you rely on unsupported fetch options or assume the runtime will automatically sanitize redirect hops, your application can fail silently or forward sensitive data to external hosts.

This guide explains how to fetch remote assets securely in Cloudflare Workers by using manual redirect handling, validating your initial targets, and explicitly rejecting unexpected 3xx responses.

The Edge Runtime Redirect Problem

The Fetch API standard defines several modes for handling HTTP redirect responses, including follow, error, and manual. However, edge environments like Cloudflare Workers execute under specific constraints. When an outbound request triggers a redirect, the runtime must decide how to handle the subsequent network hop. Developers often attempt to use options that are either unsupported for outbound Worker requests or behave unexpectedly under specific compatibility dates, causing runtime exceptions before a useful response can be parsed.

Furthermore, if your Worker fetches an asset on behalf of a user, following redirects blindly can lead to Server Side Request Forgery (SSRF) vulnerabilities. If an allowlist permits a safe domain, but that domain issues an HTTP 302 pointing to an internal metadata service or an untrusted external host, an automated redirect will bridge the gap. To prevent this, you must inspect the intermediate response rather than letting the runtime follow it automatically. For a related implementation, see Managing Concurrent Git Commits During Automated.

Validating the Initial URL

Before initiating any outbound network call, your Worker should validate the target URL. Relying solely on string matching is often insufficient because URL parsers can interpret malformed inputs in unexpected ways. Always parse the input string using the global URL constructor and check the protocol and hostname explicitly against a strict allowlist.

function isValidTargetUrl(rawUrl) {
  try {
    const parsed = new URL(rawUrl);
    const allowedHosts = ["api.trusted-domain.com", "assets.trusted-domain.com"];
    
    if (parsed.protocol !== "https:") {
      return false;
    }
    
    if (!allowedHosts.includes(parsed.hostname)) {
      return false;
    }
    
    return true;
  } catch (error) {
    return false;
  }
}

By ensuring the initial URL meets strict protocol and host requirements, you establish a secure foundation for the outbound fetch operation.

Implementing Manual Redirect Handling

To prevent the edge runtime from following redirects automatically, pass redirect: "manual" in the options object of your fetch call. When you specify manual mode, any 3xx response is returned directly to your Worker code as a standard Response object instead of triggering a transparent follow sequence.

async function secureFetchAsset(targetUrl) {
  if (!isValidTargetUrl(targetUrl)) {
    throw new Error("Target URL failed validation checks.");
  }

  const response = await fetch(targetUrl, {
    redirect: "manual",
    headers: {
      "User-Agent": "SecureWorkerAssetFetcher/1.0"
    }
  });

  if (response.status >= 300 && response.status < 400) {
    const redirectLocation = response.headers.get("Location");
    throw new Error(`Outbound request attempted a redirect to: ${redirectLocation || "unknown destination"}`);
  }

  if (!response.ok) {
    throw new Error(`Upstream service returned status: ${response.status}`);
  }

  return response;
}

In this implementation, if the upstream server responds with a 301, 302, 303, 307, or 308, the status check catches the condition immediately. The Worker aborts execution without reading the response body or forwarding sensitive headers to the Location target.

Managing Credentials and Sensitive Headers

When a redirect is followed automatically, runtime clients often propagate authorization headers, cookies, or custom tokens to the new destination. If an untrusted server captures a redirect, it can harvest these credentials.

By keeping redirect handling in manual mode, your Worker maintains complete control over token propagation. If a legitimate business requirement ever dictates that a redirect must be followed, your code must revalidate the new Location URL against your original security policy before issuing a secondary fetch call.

Testing Your Redirect Policy

To ensure your Worker handles various network responses predictably, maintain a small test matrix covering direct successes, redirects, client errors, and invalid URLs.

Test Case	Initial URL Status	Expected Behavior
Direct 200 OK	Valid trusted domain	Returns response body successfully
HTTP 302 Redirect	Trusted domain pointing elsewhere	Throws error and stops before following
HTTP 404 Not Found	Valid trusted domain	Throws upstream status error
Disallowed Host	Untrusted domain	Throws validation error immediately

Adding these verification checks alongside your production fetch path prevents regressions during runtime updates and ensures your edge applications maintain strict security boundaries.

Conclusion

Outbound fetch operations in edge runtimes require deliberate security controls to prevent unintended data exposure and SSRF vulnerabilities. By validating initial target URLs, configuring manual redirect policies, and explicitly inspecting 3xx status codes, you protect your infrastructure from unsafe redirects while maintaining predictable performance at the edge.