charl-kruger · May 15, 2026 08:51 · charl-kruger · May 15, 2026 · charl-kruger · May 15, 2026
diff --git a/gistfile1.txt b/gistfile1.txt
 ## Verdict

 **I would not approve the standard `surfly.js` integration for authenticated or transactional banking pages as-is.** It is not just a “support widget”; it is a third-party JavaScript loader plus a co-browsing/proxy system that can interact with authenticated browser state, page contents, navigation, events, files, screenshots, and session control. That threat model is too powerful for core banking unless it is heavily isolated, hardened, independently reviewed, and preferably deployed in a controlled/private/on-prem model.

 One important limitation: I could not retrieve the raw live `https://surfly.com/surfly.js` body through the available web reader because it rejected the JavaScript content type, and the execution container could not resolve the host. So this is **not** a line-by-line audit of the minified live asset. For a banking approval, that alone is a gating issue: you should require the exact source, sourcemaps where applicable, a version-pinned artifact, dependency inventory, hashes, and change-control evidence before go-live. The public docs and integration model are still enough to conclude that the default/public SaaS integration is not suitable for sensitive banking flows.

 ---

 ## What Surfly is actually doing

 The documented integration dynamically injects a remote script from `https://surfly.com/surfly.js` into the page, asynchronously loads the Surfly libraries, and then exposes `Surfly.init()` and other API methods to the host page. The current quickstart explicitly shows a loader that creates a `<script>` element, sets `async = 1`, and sets `src` to `https://surfly.com/surfly.js`; it also notes that the rest of the API is not available until initialization is ready. ([docs.surfly.com][1])

 Architecturally, Surfly describes itself as JavaScript plus a **content-rewriting proxy**. In a session, the leader browser’s request goes to the Surfly proxy, the proxy modifies the request to look as if it came from `surfly.com`, sends it to the original site, receives the response, modifies that content so it can load inside an iframe, and synchronizes interaction between leader and follower browsers. Surfly’s own docs say the proxy “overcomes cross-domain policies” and allows co-browsing of logged-in sessions while not sending security tokens/passwords to the follower. ([docs.surfly.com][2])

 That is a powerful model. It means a banking site would be adding a third-party runtime and proxy-based browsing layer into the same customer journey where balances, account numbers, payment forms, identity flows, tokens, statements, and fraud controls may exist.

 ---

 ## Main security conclusion

 **This is not secure enough for a banking platform in its default or typical documented form.**

 It may be acceptable only for a constrained use case such as:

 **“Agent can view and guide a user on a non-transactional support surface, with sensitive fields masked, no agent control, no cookie/storage transfer, no file sharing, no screenshots/recording, no arbitrary navigation, strict allowlisting, server-side transaction blocking, version-pinned code, and independent audit of the actual Surfly JavaScript and proxy.”**

 For anything involving authenticated balances, statements, onboarding KYC, card data, payments, beneficiary creation, loan applications, password reset, OTP entry, PIN entry, or privileged admin actions, I would treat it as **not approved unless isolated into a specially designed support environment**.

 ---

 ## Critical findings

 ### 1. Third-party JavaScript supply-chain risk is fundamental here

 The bank page loads executable JavaScript from Surfly’s domain. The documented snippet does not show Subresource Integrity, an immutable versioned asset URL, or a pinned hash; it dynamically loads `https://surfly.com/surfly.js`. ([docs.surfly.com][1])

 That matters because third-party JavaScript executes with the privileges of the embedding page. OWASP’s third-party JavaScript guidance describes this class of risk as effectively comparable to XSS: the script can execute in the user’s browser context, and key risks include arbitrary code execution, loss of control over upstream changes, and sensitive-data leakage. ([OWASP Cheat Sheet Series][3])

 For a bank, a compromised or maliciously changed `surfly.js` could potentially:

 * Read or alter DOM content, including balances, names, account details, form fields, and transaction screens.
 * Trigger same-origin requests to banking APIs from the customer’s browser; HttpOnly cookies would still be attached by the browser even if JavaScript cannot read them directly.
 * Manipulate payment or beneficiary forms before submission.
 * Capture interaction telemetry, form values, navigation state, or screenshots depending on configuration and runtime behavior.
 * Bypass the bank’s own release/change-control process because code is being pulled from a third-party origin at runtime.

 This is not an allegation that Surfly is malicious. It is an inherent risk of placing mutable third-party JavaScript inside authenticated banking pages.

 ---

 ### 2. The proxy model is a deliberate man-in-the-browser / man-in-the-session pattern

 Surfly’s technology documentation says the user’s web requests are routed through a Surfly proxy, that the proxy rewrites responses so they can be loaded in an iframe, and that this mechanism is designed to overcome cross-domain restrictions. ([docs.surfly.com][2])

 That is exactly the kind of mechanism banks usually design controls to prevent. Banking security often depends on origin boundaries, device/session binding, anti-clickjacking, CSP, secure cookies, SameSite behavior, fraud telemetry, bot detection, step-up authentication, and transaction-signing semantics. A proxy that rewrites content and synchronizes browser activity can interfere with or complicate those controls.

 Surfly says security tokens and passwords are not sent to followers, and that followers see only visual changes. ([docs.surfly.com][2]) That is useful, but it is not enough for banking approval. The bank would still need to prove exactly where sensitive data is visible, where it is processed, whether it is transformed before or after leaving the customer browser, what the proxy can see, what is logged, what metadata is stored, and how session state is handled.

 ---

 ### 3. Cookie, storage, and form transfer defaults are dangerous for banking

 Surfly’s session options document shows `cookie_transfer_enabled` defaults to `true`, and describes it as transferring cookies, localStorage, sessionStorage, and form fields into the session and back, excluding form fields on the back-transfer. It also documents `cookie_transfer_proxying`, which can transfer HttpOnly cookies between the session and original page when configured with a continuation point. ([docs.surfly.com][4])

 For banking, this is a major red flag.

 Bank authentication state is often stored across Secure/HttpOnly/SameSite cookies, localStorage, sessionStorage, browser-bound tokens, anti-CSRF state, device-binding values, and fraud-analysis identifiers. A co-browsing product that can transfer or proxy these values can undermine assumptions made by the bank’s session-management design.

 At minimum, a banking configuration should disable cookie/storage transfer unless there is a very carefully reviewed, narrow, non-authenticated support use case. I would consider these settings unacceptable on core banking pages:

 ```js
 cookie_transfer_enabled: true
 cookie_transfer_proxying: true
 enable_cookie_backtransfer: true
 ```

 The safe posture for banking is to avoid transferring authentication state into a co-browsing context at all.

 ---

 ### 4. Masking is useful, but fragile and not sufficient

 Surfly documents field masking and says password fields are masked by default, while other fields require either the `surfly_private` attribute or configuration such as `hide_element_by_selector`. It also documents an important limitation: masked fields inside `GET` forms, or masked values that become part of URLs, may still be trackable through audit logs and browser network activity. ([docs.surfly.com][5])

 That limitation is highly relevant for banking. Sensitive values often appear not just in visible fields but also in:

 * URLs and query parameters.
 * Hidden fields.
 * DOM attributes.
 * Client-side state stores.
 * JavaScript variables.
 * Analytics events.
 * Error messages.
 * Download URLs.
 * Statement/document viewers.
 * Shadow DOM or dynamically rendered components.
 * Autocomplete and browser-managed inputs.

 Masking is an implementation detail, not a security boundary. A bank should not rely on CSS selectors or field attributes as the primary control protecting account numbers, card numbers, balances, OTPs, PINs, KYC information, payment details, or statement data.

 ---

 ### 5. Default session-control options are too permissive

 The documented defaults include several settings that are risky for a bank. Surfly’s options show `host_switching_allowed: true`, `participants_can_request_to_interact: true`, `new_urls_allowed: true`, `non_hosts_can_open_tabs: true`, and `allow_opening_urls_from_query_parameter: true`. The same options list shows `private_session: false`, `password_required: false`, and `admission_enabled: false` by default. ([docs.surfly.com][4])

 Surfly’s session API also exposes leader/follower links, PINs, host switching, tab control, control transfer, URL relocation, file upload, screenshots, and broadcast messaging. ([docs.surfly.com][6])

 For banking, these defaults are not acceptable. A leaked follower link, weak join process, permissive control transfer, arbitrary navigation, or accidental screen-share into sensitive pages could expose regulated data. Even if Surfly has server-side protections, the integration should start from a denial posture: no arbitrary navigation, no default invitations, no agent control, no participant control request, no host switching, no file upload, no screenshot, and no recording unless there is a specific approved need.

 ---

 ### 6. The messaging bridge can become a cross-context attack surface

 Surfly documents `sendMessage(message, targetOrigin)` for communication between the original page and proxified version, and explicitly notes that using `targetOrigin = "*"` delivers the message regardless of recipient origin. ([docs.surfly.com][6])

 That creates an integration risk. If the bank’s application, Surfly widget, or session extensions use permissive message handling, this can become a cross-origin bridge problem: sensitive data or commands may be sent to the wrong context, or untrusted contexts may influence the banking page.

 For a bank, any `postMessage`-style integration must use exact origin checks, strict schema validation, replay protection where needed, and no wildcard target origins for sensitive messages.

 ---

 ### 7. Audit logs, screenshots, file sharing, chat, and events can leak sensitive data

 Surfly documents audit logging for actions such as button clicks, text inputs, control transfers, documents shared, and pages visited. The docs also list events containing page URLs, form changes, submissions, clicks, participant metadata, IP addresses, names, and control transfers. ([docs.surfly.com][5])

 The JS API also exposes events such as user activity, relocation, tab control, file download, messages, and session lifecycle events. Some events include URLs, filenames, user data, origins, and final locations. ([docs.surfly.com][7])

 For normal customer support, this may be useful. For banking, it can become a regulated-data leakage path. Page URLs can contain identifiers. File names can reveal statements or claims. Form-change logs can accidentally capture customer input. Screenshots can capture balances, statements, KYC documents, or card details. Chat logs can contain PII or authentication information.

 Surfly does provide controls for audit logs, screenshots, video, screen sharing, file sharing, and privacy options, but the existence of these capabilities means the bank needs a strict data-retention and data-minimization design rather than a simple widget integration. ([docs.surfly.com][4])

 ---

 ### 8. Client-side “disable submit button” controls are not enough

 Surfly’s security documentation includes an example approach for disabling submit buttons while an agent has control. ([docs.surfly.com][5])

 That may reduce accidental agent actions, but it is not a banking-grade control. Any control implemented only in browser JavaScript can be bypassed by bugs, DOM changes, race conditions, malicious scripts, browser devtools, API calls, or integration mistakes.

 For banking, transactional protection must be enforced server-side. Examples:

 * Agents must never be able to initiate or approve payments.
 * Agent-controlled sessions must be blocked from payment, beneficiary, card-management, loan-approval, password-reset, OTP/PIN, or statement-download endpoints.
 * “Customer in control” must be proven server-side, not inferred from a button state.
 * Step-up authentication must occur outside the co-browsing context where possible.
 * Transaction signing must bind the exact beneficiary, amount, and account to the customer’s authenticated approval.

 ---

 ## Medium-risk findings

 ### Domain allowlisting is not a sufficient boundary

 The docs require domains to be added to a widget key domain list, with examples such as `*example.com` or `*.example.com`. ([docs.surfly.com][1])

 That helps prevent casual misuse of a widget key, but it does not solve the core risks. It does not constrain what the loaded JavaScript can do once it is running on an approved banking origin. Wildcard subdomain patterns can also become dangerous if any subdomain is vulnerable to takeover, XSS, or weak hosting controls.

 ---

 ### The documented loader lacks visible SRI protection

 The snippet does not show an `integrity` attribute or a pinned versioned URL. SRI is specifically designed to let browsers verify that a fetched script matches an expected cryptographic hash and detect unexpected tampering. ([OWASP Foundation][8])

 For a banking platform, a mutable third-party script URL without SRI or version pinning is a major supply-chain concern. Dynamic SaaS JavaScript may be operationally convenient, but it is hard to reconcile with banking change-control requirements unless the bank has compensating controls such as self-hosting, a private build, strict CSP, hash monitoring, and contractual change notification.

 ---

 ### User metadata can become PII leakage

 Surfly allows user data such as name and email to be passed into sessions and displayed in queues/events. ([docs.surfly.com][6])

 That means integration teams must treat Surfly session metadata as regulated customer data. Do not pass full customer identifiers, account numbers, phone numbers, national IDs, or unnecessary email addresses unless explicitly approved by privacy and legal teams. Use opaque internal support identifiers instead.

 ---

 ## Banking approval recommendation

 ### Do not approve this configuration

 I would reject the following pattern for banking:

 ```html
 <script>
  // Standard Surfly loader from surfly.com
  // included on authenticated banking pages
 </script>
 ```

 especially if combined with:

 ```js
 cookie_transfer_enabled: true,
 cookie_transfer_proxying: true,
 host_switching_allowed: true,
 participants_can_request_to_interact: true,
 new_urls_allowed: true,
 non_hosts_can_open_tabs: true,
 allow_opening_urls_from_query_parameter: true,
 filesharing_enabled: true,
 screensharing_enabled: true,
 audit_logs_enabled: true,
 automatic_screenshots_enabled: true,
 private_session: false,
 password_required: false,
 admission_enabled: false
 ```

 That configuration is too permissive for banking.

 ---

 ## Minimum hardening profile if the bank still wants Surfly

 The safer design is to **not load Surfly at all on the real online-banking app**. Instead, create a separate support surface that contains only the minimum information required for troubleshooting.

 A hardened Surfly-style configuration should look conceptually like this, with exact option names validated against your Surfly tenant/version:

 ```js
 Surfly.init({
  widget_key: "REDACTED",

  // Keep Surfly out of ordinary browsing where possible
  embedded_sessions_only: true,
  session_start_confirmation: true,

  // Join/session protection
  private_session: true,
  password_required: true,
  admission_enabled: true,
  default_invitations_enabled: false,
  invitations_allowed: false,

  // No agent/customer role switching unless formally approved
  host_switching_allowed: false,
  participants_can_request_to_interact: false,

  // Prevent arbitrary navigation
  new_urls_allowed: false,
  non_hosts_can_open_tabs: false,
  allow_opening_urls_from_query_parameter: false,

  // Strict URL allowlisting
  allowlist: JSON.stringify([
    {
      pattern: "^https://bank\\.example/(support-safe|help)(/|$)",
      type: "all"
    }
  ]),

  // Avoid transferring banking auth/session state
  cookie_transfer_enabled: false,
  cookie_transfer_proxying: false,
  enable_cookie_backtransfer: false,

  // Disable high-risk data movement
  filesharing_enabled: false,
  download_trigger_enabled: false,
  videochat: false,
  screensharing_enabled: false,
  automatic_screenshots_enabled: false,
  automated_session_recording_enabled: false,

  // Logs should be off unless privacy/legal approve exact fields and retention
  audit_logs_enabled: false,
  chat_logs_enabled: false,

  // Mask aggressively, but do not rely on masking as the main boundary
  hide_element_by_selector:
    "[data-sensitive], .balance, .account-number, .iban, .card-number, .pan, .otp, .pin, .statement, .transaction-history, form[action*='payment'] *"
 });
 ```

 That is still not enough by itself. The bank also needs server-side controls.

 ---

 ## Required server-side controls

 For a banking platform, the server must enforce the real security boundary:

 1. **Block transactional endpoints during co-browsing.** Payments, transfers, beneficiary changes, password resets, OTP/PIN changes, card controls, personal-data updates, and document downloads should be blocked or forced into customer-only flows.

 2. **Do not trust client-side Surfly state.** Headers such as Surfly detection headers should be treated carefully. Strip spoofable headers at the edge and only trust signals inserted by a controlled reverse proxy or trusted infrastructure.

 3. **Use a separate support origin or path.** Example: `support.bank.example`, not the main authenticated banking app.

 4. **No sensitive values in URLs.** Surfly’s own docs warn that masked values used in GET forms or URLs can still be exposed through logs/network activity. ([docs.surfly.com][5])

 5. **Require exact origin validation for messaging.** No wildcard `targetOrigin: "*"` for sensitive messages.

 6. **Use least-privilege agent access.** Agents should authenticate with SSO/MFA, have scoped permissions, and be unable to join sessions without customer approval.

 7. **Keep customer secrets out of the session.** OTPs, PINs, passwords, card CVVs, recovery codes, and transaction-signing prompts should never be visible or controllable in a co-browsing session.

 8. **Use data-loss prevention on logs and recordings.** Prefer no screenshots, no recording, no chat logs, and no audit payloads containing form values unless explicitly required and redacted.

 ---

 ## Evidence I would demand from Surfly before approval

 Before using this in a bank, I would require:

 * Exact source code for the deployed `surfly.js`, including minified and unminified versions.
 * Version-pinned JavaScript artifact, immutable URL, and SRI-compatible hash.
 * SBOM for JavaScript, proxy, backend, browser-extension/session components, and dependencies.
 * Independent penetration test covering the Surfly proxy, session join links, PINs, WebSocket/session channels, masking, logging, screenshots, file transfer, and `postMessage` bridge.
 * Documentation of exactly what data the Surfly proxy can see in authenticated sessions.
 * Proof of how masking works: before data leaves the customer browser, inside the proxy, or only in the follower rendering.
 * Token/link entropy, TTLs, revocation behavior, brute-force protection, and leak handling.
 * Controls for follower-link sharing, admission, identity verification, and agent impersonation.
 * CSP guidance for banking pages.
 * Confirmation that Surfly can run with no cookie/localStorage/sessionStorage transfer.
 * Logs/recordings retention policy, encryption, deletion SLAs, and data residency guarantees.
 * A private/on-prem deployment option evaluation, since Surfly’s own docs mention on-prem installation as an option. ([docs.surfly.com][2])

 ---

 ## Final risk rating

 **Default/public Surfly integration on authenticated banking pages: Critical risk — not approved.**

 **Hardened Surfly on a segregated, non-transactional support surface: Potentially approvable after source review, proxy review, strict configuration, independent pen test, legal/privacy review, and server-side transaction blocking.**

 **Use inside real online banking flows involving balances, payments, statements, KYC, credentials, OTPs, PINs, or card data: Not recommended.**

 The core reason is simple: Surfly’s value proposition is the same thing that makes it risky for banking. It gives a third-party script and proxy enough visibility and control to make co-browsing work. In a low-risk website, that may be acceptable. In a banking platform, that is a privileged session-interposition mechanism and must be treated like a high-risk extension of the bank’s trusted computing base.

 [1]: https://docs.surfly.com/surfly/javascript-api/quickstart "Quickstart | Documentation Portal"
 [2]: https://docs.surfly.com/surfly/technology/ "Surfly Technology | Documentation Portal"
 [3]: https://cheatsheetseries.owasp.org/cheatsheets/Third_Party_Javascript_Management_Cheat_Sheet.html?utm_source=chatgpt.com "Third Party JavaScript Management Cheat Sheet - OWASP"
 [4]: https://docs.surfly.com/surfly/session-options "Co-Browsing session options | Documentation Portal"
 [5]: https://docs.surfly.com/surfly/tutorials/security-functionalities "Security functionalities | Documentation Portal"
 [6]: https://docs.surfly.com/surfly/javascript-api/surfly-session "Sessions | Documentation Portal"
 [7]: https://docs.surfly.com/surfly/javascript-api/surfly-events "Events | Documentation Portal"
 [8]: https://owasp.org/www-community/controls/SubresourceIntegrity?utm_source=chatgpt.com "Subresource Integrity (SRI) - OWASP Foundation"
Component	Confidence	Security relevance
`@sentry/browser` / Sentry JS SDK	Confirmed	Error telemetry, breadcrumbs, request/context capture
Sentry SDK version `7.120.4`	Confirmed	Version visible in bundle
Sentry `GlobalHandlers`	Confirmed	Captures global errors
Sentry `RewriteFrames`	Confirmed	Rewrites stack frames to `~/static/bundles/widget/apiframe.js`
Sentry `Breadcrumbs`	Confirmed	Instruments console, DOM, fetch, history, XHR
`fbemitter`-style `EventEmitter`	High confidence	Internal event bus
`node-polyglot`-style translation system	High confidence	UI translations
`punycode`	Confirmed	URL/domain conversion
`object.entries` / `object-keys` / intrinsic/polyfill helpers	High confidence	Bundled compatibility/polyfill code
Area	Risk	Reason
Third-party script supply chain	Critical	Remote mutable code runs in banking page context
Form-state handling	Critical	Inputs, textareas, selects, contenteditable, iframes, and scroll state can be serialized/restored
Storage handling	Critical	`localStorage` and `sessionStorage` collection path exists
Cookie/session transfer	Critical	Cookie restore and proxying/continuation paths exist
Transaction integrity	Critical	Control/navigation/tab APIs can influence session flows
Data privacy	High/Critical	PII and financial data exposure through DOM, storage, telemetry, logs, screenshots, chat, file events
Telemetry	High	Sentry is embedded and browser breadcrumbs are present
UI overlay/phishing	High	Full-page overlays and very high z-index
Source transparency	High	No source map available, no full SBOM
Config-hardening dependency	High	Safety depends heavily on correct Surfly configuration and correct bank integration
Sentry data path	Risk	Why
Hardcoded Sentry DSN to `sentry.io`	High	Third-party telemetry egress from banking pages
`user_settings: JSON.stringify(...)`	Critical	Can expose integration config and accidental PII
`widget_key` tag	High	Tenant/widget identifier leaves page
`sessionId` tag	High	Correlates errors to Surfly sessions
`settings` extra	High	Exposes effective Surfly configuration
`user_data` extra	Critical	Can expose customer PII if integrator passes it
URL/referrer/user-agent	High	Banking URLs often contain sensitive route context
Console breadcrumbs	High	Debug logs often leak sensitive objects
DOM breadcrumbs	Medium/high	Can reveal form/page semantics
XHR/fetch breadcrumbs	Medium/high	API URLs and status codes expose workflow details