Infrastructure

Webfuse is hosted across the globe, premised on multiple edge-performance data centers. For optimal Session performance, Webfuse assures that users by default are connected to the nearest available host within the server network. Webfuse acts much like an adaptive content delivery network, similar, e.g., Akamai or Cloudflare.

System Architecture

All requests in Session are routed through Webfuse, which means that a Webfuse user’s browser will never connect directly to the originally requested web application. Instead, Webfuse will transact the communication on behalf of the user and forward requested resources, augmented and enhanced based on related Space configurations, Extensions, and Apps. Webfuse, that said, is an all-in-one is high-performance forwarding and reverse proxy: a web proxy.

Perspective: Virtual Browser

A Session is basically a regular browser Session. If integrated seamlessly, such as below a custom domain, users will usually not know that they are browsing though Webfuse, unless the virtual Session UI is shown. With a Session UI, new Tabs within a Session will be created as Virtual Tabs, i.e., live within the same physical browser tab.

On a technical level, Webfuse represents a web proxy. Usability wise, however, you could also interpret it as a virtual web browser, which is embedded into a web application opened in a real web browser.

Additional Headers

Webfuse sets specific headers to compile and preserve information about the related HTTP transaction. These additional headers provide transparency and traceability when dealing with Sessions. They can help ensure secure communication and enable backend systems to validate the authenticity of requests.

Header	Description	Example
Surfly-Forwarded	This request header contains the IP address of the original requester. It retains the original ‘forwarded-for’ header and can be either an IPv4 or IPv6 address. This information is useful for tracking the source of the request.	::ffff:127.0.0.1
X-Surfly-Sessionid	This request header uniquely identifies the Webfuse Session. It can be used by the target application to verify that a request originated from Webfuse. To ensure the authenticity of the Session, verify the Session ID with a REST call to the Webfuse server.	f50zXqx3p1UZQQSknH4qdkjABg
Surfly-Proxy-Metrics	This response header provides detailed timing information about various stages of processing a request in the platform.	req_read: 5, resp_read: 10, decomp: 2, decode: 3, detect_akamai: 1, chardet: 1, html: 20, css: -, js: -, rstr: 2, t: 59

Note

The Headers App allows you to set custom headers yourself.

Request Timing Metrics

To help you understand the performance of Webfuse and a particular Session, Webfuse also exposes the following metrics in the Surfly-Proxy-Metrics response header value:

Metric	Description
req_read	Time taken to read the request body from the reverse proxy.
resp_read	Time taken to read the response body from the forward proxies.
decomp	Time taken to decompress the response received from the forward proxies.
decode	Time taken to decode the response body to Unicode before processing.
detect_akamai	Time taken to detect if the response is served by Akamai.
chardet	Time taken to detect the encoding of the response body.
html	Time taken to process the HTML of the response.
css	Time taken to process the CSS of the response.
js	Time taken to process the JavaScript of the response.
rstr	Time taken to apply restrictions to the response.
t	Total time taken to prepare the response.

Example

A Surfly-Proxy-Metrics response header might look like this:

Surfly-Proxy-Metrics: req_read: 5, resp_read: 10, decomp: 2, decode: 3, detect_akamai: 1, chardet: 1, html: 20, css: -, js: -, rstr: 2, t: 59

This indicates the time (in milliseconds) taken for each stage of processing. - indicates that the time is not applicable for the particular request.

Content Rewriting

The core of Webfuse is the web proxy capabilities: a full-featured HTTPS and WebSocket proxy that is able to handle traffic from any modern web application. It parses and modifies the traffic on the fly in such a way that all subsequent traffic will be routed through the proxy. This means, among other things, that all the URLs of served pages are rewritten, so they point to proxied versions of the target URLs.

But that’s just where it starts. Anyone familiar with web server rewriting modules (such as ARR in IIS or mod_rewrite in Apache) knows that having rewrite rules inside the HTTP proxy is very limited. Modern web apps rely on JavaScript, so most of the content is actually generated on the client side. For example, the code below would create a link that is virtually impossible to capture by the proxy:

const currentDate = new Date();
const link = document.createElement('a');
//At the time of writing, this would generate a link to https://the-year-2025.test
link.href = 'https://the-year-' + currentDate.getFullYear() + '.test';
document.body.appendChild(link);

Moreover, the JavaScript code itself could be dynamically generated:

let foo = {};
const code = 'foo.href = "//example.com"';
eval(code); //this will not do anything
foo = window.location;
eval(code);  //this time the page will navigate to example.com

And if that is not enough, the code could be obfuscated. This code does exactly the same as the one above:

const _0x5c2c=['foo.href\x20=\x20\x22//example.com\x22','703271gmlQyD','381497emYCfi',
'1019923hJJvMQ','603QLrHWo','383617OfWLUT','location','1177365yPaujx',
'1559GDizPw','648076JfmmxG'];const _0x34f2=function(_0x11440c,_0x3244b0){_0x11440c=_0x11440c-0x17d;let _0x5c2cf2=_0x5c2c[_0x11440c];return _0x5c2cf2;};const _0x452fd3=_0x34f2;(function(_0x4f836c,_0xafd59a){const _0x5094f6=_0x34f2;while(!![]){try{const _0x516045=parseInt(_0x5094f6(0x185))+-parseInt(_0x5094f6(0x183))+-parseInt(_0x5094f6(0x17f))+parseInt(_0x5094f6(0x181))+-parseInt(_0x5094f6(0x186))*-parseInt(_0x5094f6(0x180))+-parseInt(_0x5094f6(0x184))+parseInt(_0x5094f6(0x17d));if(_0x516045===_0xafd59a)break;else _0x4f836c['push'](_0x4f836c['shift']());}catch(_0x8adaf){_0x4f836c['push'](_0x4f836c['shift']());}}}(_0x5c2c,0xb21d8));let foo={};const code=_0x452fd3(0x182);eval(code),foo=window[_0x452fd3(0x17e)],eval(code);

In order to handle these and other tricky cases, Webfuse maintains a fully controlled JavaScript sandbox. This allows Webfuse to apply custom wrapper functions to all execution points, such as function calls and object property access. These wrappers are executed in runtime inside the browser, so it allows us to intercept all relevant Web API requests and change the return value before giving it back to the application code.

Together, the JavaScript sandbox and the network proxy can practically capture all inputs and outputs of any web application, forming together the ingredient of the virtual web Session that a user will experience in its browser, where all the resulting changes will be rendered locally.

Security & Privacy

Webfuse is built with security and privacy at its core, ensuring that all interactions within a Virtual Web Session remain isolated, secure, and compliant. Unlike traditional web augmentation solutions that rely on cloud-based rendering or remote execution, Webfuse ensures that all content is rendered locally on the user’s device, eliminating unnecessary exposure to third-party servers.

Key Security Features

• Everything is Locally Rendered
  • Webfuse operates directly within the user’s browser, meaning no content is streamed or processed remotely.
  • This prevents third-party interception of sensitive web interactions.
• No Session Data is Stored by Default
  • By design, Webfuse does not persist Session data, cookies, or browsing history beyond the active Session.
  • Once a Session ends, all temporary data is erased, ensuring zero residual exposure.
• Bring Your Own Storage (Optional)
  • For organizations that require audit logging, Session recording, or compliance tracking, Webfuse allows full control over data storage.
  • Companies can configure their own secure storage endpoints (e.g., AWS S3, on-premise storage) to retain logs without relying on third-party servers.
• Enterprise-Grade Compliance & Certifications
  • ISO 27001 Certified - Webfuse follows international best practices for information security management.
  • SOC 2 Audit Report Available - Ensuring transparency, integrity, and security of data handling processes.

Webfuse’s privacy-first architecture ensures that organizations retain full control over their data, eliminating reliance on third-party storage while maintaining compliance with GDPR, HIPAA, and other regulatory frameworks. By rendering everything locally on the user’s device and storing no Session data by default, Webfuse minimizes the attack surface and prevents unauthorized access to sensitive information. For businesses requiring audit logs or Session recordings, Webfuse allows full flexibility to use their own secure storage endpoints, avoiding vendor lock-in while ensuring data sovereignty and enterprise-grade security.

Note

With Webfuse, you get many security features out-of-the-box. More advanced security Use Cases can be configured through Session Settings, and Apps.