Client-Side vs. Server-Side Redaction: Architecture Analysis

Two Approaches to Log Sanitization

When designing software tools to scrub sensitive data (like database connections, passwords, and user PII) before sharing with external AI engines, developers face a core architectural choice: should the sanitization logic run on a remote server, or locally within the user's web browser?

Both architectures have distinct trade-offs in execution speed, rule complexity, network security, and compliance safety. Let's compare their design parameters.

Server-Side Redaction Architecture

In a server-side sanitization model, the developer pastes text into the web portal, which then sends the payload via an HTTP POST request to a backend API server. The API server runs detection scripts (such as pattern libraries or NLP models) and returns the sanitized text to the user.

Weaknesses of this model:

• Transit Risk: Your raw database connection strings and passwords travel over public networks. Any intercept or misconfigured TLS setup exposes the credentials.
• Storage Surface: The server processing the logs could cache them, store them in temporary diagnostic databases, or leak them via server application logs.
• Trust Dependency: You must trust the third-party provider's backend security practices, database hygiene, and access protocols.

Client-Side Redaction Architecture (Zero-Server)

In a client-side (local-first) architecture—which is the model used by ScrubBeforeAI—the parsing and regex matching logic are loaded into the browser as a static script during the initial page load. Once loaded, all operations occur strictly inside the browser sandbox in your local system memory.

Strengths of this model:

• Zero Transmission: Because no API requests are sent, your raw credentials never travel over the network. Your logs never leave your physical computer.
• No Server Logs: Since there is no backend server, there are no databases, caching layers, or logs that could leak in a server security breach.
• Offline Execution: By leveraging Service Workers (PWA), the entire app operates without an active internet connection, matching secure air-gapped dev environments.

Comparison Matrix

Local Storage Security: sessionStorage vs. localStorage

Even in a client-side architecture, keeping reversal maps (which map placeholders back to credentials) requires security controls. Utilities should distinguish between storage mediums:

• localStorage: Writes data permanently to the user's hard drive. It survives browser restarts, presenting a security vulnerability if other applications inspect browser cookies or storage files.
• sessionStorage: Stores data in memory isolated per browser tab. The moment a user closes the browser tab, the lookup mapping is destroyed instantly, preventing any offline forensic analysis of hard drives.

Conclusion

For developer security tools, client-side execution is the superior architectural model. It eliminates transit vulnerabilities, avoids data custody responsibilities, and satisfies regulatory requirements by keeping passwords, API keys, and stack traces exactly where they belong: locally in your workspace.