FAQs

Why aren't requestExtensionData payloads encrypted?

Updated:

Tecton does not apply application-layer encryption to requestExtensionData payloads, and adding it with your extension does not necessarily improve security.

The postMessage channel is in-browser

requestExtensionData works by sending a Tecton message from your extension's iframe to the Tecton platform window running in the same browser session. This channel is entirely in-process — it never touches a network. The browser's security model controls who can send and receive these messages, and no outside party can observe or intercept them.

Adding encryption to this channel with a key that lives in the browser provides no confidentiality benefit. An attacker with access to the browser context (e.g., through DevTools or a compromised extension) can read the key just as easily as the payload itself. Beyond being ineffective, application-layer encryption adds CPU overhead and latency on every request without closing any real security gap.

Where transport security actually matters

The network hop — from the platform to your extension's backend — is where encryption matters, and TLS (HTTPS) already handles it. You may notice the platform base64-encodes the payload before sending it over the network; this is a serialization convention, not encryption, and does not provide confidentiality.

When field-level encryption is appropriate

There are legitimate cases where encrypting specific fields before placing them in body makes sense — for example, if your threat model requires that the platform cannot read certain values, if a shared proxy or logging layer sits between the platform and your backend, or if a compliance requirement mandates field-level encryption for specific data types.

When this applies, the encryption should be implemented in your feature, not in Tecton. The reason is that the encryption key must be managed server-side and never accessible from the browser — otherwise an attacker can extract it and the protection is meaningless. Because the key exchange and encryption scheme are specific to your backend and your data, Tecton has no meaningful way to provide this generically. Your feature fetches or derives a key through a secure server-side handshake, encrypts the relevant fields before calling requestExtensionData, and your backend decrypts them on receipt.

Tecton passes the body object through to your backend opaquely, so the encrypted fields will be delivered as-is.

Associated Pages