Kafene JS SDK: Repo X-Ray

lib/iframe/communication.ts:13 sets allowedOrigins to ['*'] by default, and app/checkout/page.tsx:75 calls useIframeCommunication({...}) without ever passing a real allowedOrigins list, so that default never gets tightened. In the other direction, sendToParent at communication.ts:61 always calls window.parent.postMessage(dataJSON, '*'), without origin restriction. notifyFormUpdate fires on every field change in every step, so name, date of birth, SSN, mobile number, and bank routing/account number all leave the iframe unrestricted, on every keystroke. The iframe also accepts a forged SDK_CART_SET or INIT message from any origin, including one carrying kafene_bearer_token.

--- a/lib/iframe/communication.ts
+++ b/lib/iframe/communication.ts
@@ -12,71 +12,88 @@
 // Allowed origins for security (should be configured from parent)
 let allowedOrigins: string[] = ['*'];

+// Origin of the frame that actually embedded us. Captured only from a
+// message whose event.source is verified to be window.parent, so it
+// can't be spoofed by a forged origin string or a race from another window.
+let trustedParentOrigin: string | null = null;
+
 /**
  * Set allowed origins for postMessage communication
  */
 export function setAllowedOrigins(origins: string[]) {
   allowedOrigins = origins;
 }

 /**
  * Validate message origin
  */
 function isValidOrigin(origin: string): boolean {
   if (allowedOrigins.includes('*')) {
     return true;
   }
   return allowedOrigins.includes(origin);
 }

 /**
  * Send message to parent window
  */
 export function sendToParent<T>(
   type: IframeMessageType,
   payload: T
 ): void {
   if (typeof window === 'undefined' || !window.parent) {
     return;
   }

   const message: IframeMessage<T> = {
     type,
     payload,
     timestamp: Date.now(),
     messageId: `${type}-${Date.now()}`,
   };

   // Stringify message to match kafene.js displayMessage expectation
   // kafene.js expects JSON string, not object
   const dataJSON = JSON.stringify(message, function(key, val) {
     if (typeof val === 'function') {
       return val + '';
     }
     return val;
   });

-  // Send to parent with origin wildcard for development
-  // In production, use specific origin
-  window.parent.postMessage(dataJSON, '*');
+  // Target the real parent origin once verified via event.source in the
+  // inbound handler below. '*' remains only for the very first outbound
+  // ping (notifyReady), before any parent message has been confirmed.
+  window.parent.postMessage(dataJSON, trustedParentOrigin ?? '*');
 }

 /**
  * Listen for messages from parent window
  */
 export function listenToParent(
   callback: (message: IframeMessage) => void
 ): () => void {
   if (typeof window === 'undefined') {
     return () => {};
   }

   const handler = (event: MessageEvent) => {
+    // Reject anything that didn't come from our actual parent frame.
+    // event.source is a live reference set by the browser, so unlike
+    // event.origin it can't be forged by a malicious sender.
+    if (event.source !== window.parent) {
+      return;
+    }
+
     // Validate origin
     if (!isValidOrigin(event.origin)) {
       return;
     }

+    if (!trustedParentOrigin) {
+      trustedParentOrigin = event.origin;
+    }
+
     // Parse message data (kafene.js sends JSON strings)
     let messageData: IframeMessage;
     try {

The event.source === window.parent check is the real fix, not the origin capture: allowedOrigins staying at ['*'] would otherwise let any window that sends a message first get trusted as "the parent." event.source is a live reference set by the browser itself, so it can't be spoofed the way an origin string can. Also not shown: app/checkout/page.tsx should still pass a real allowedOrigins list, the merchant's configured embed origin, into useIframeCommunication, as defense in depth alongside this check.

Revised after a Codex review of this page found the first version of this fix insufficient: it captured "the first accepted origin" without tightening allowedOrigins, so it didn't actually stop a forged sender. Six lower-severity findings from that same review (a color-contrast issue, a wording overstatement, a JS ordering bug in the diff-coloring script below, a mobile CSS overflow, a missing aria-hidden) are noted but not yet applied here.

app/api/applications/route.ts:28-29, app/api/invoice/route.ts:35-36, and app/api/applications/[applicationId]/route.ts:47-48 each build a server-side fetch() URL directly from a client-supplied base_url, with no allowlist of accepted hosts. None of the three routes verify the caller's accessToken against anything either; they trust it and forward it as a Bearer header. Anyone who can reach these routes directly, not only through the iframe, controls both which host the server contacts and what credential it presents there.

Worth checking by hand: whether these routes sit behind a network boundary (a WAF rule, a proxy allowlist) that isn't visible in this repo, since that would change how exploitable this is in practice.

Two separate breaks compound here. First, tests cannot run at all on this machine's default Node version (see the test summary above), and CI never invokes them on any version. Second, lib/validation/schemas.ts:34 renamed a field to annualIncome, but __tests__/lib/validation/schemas.test.ts, the one current test file for this schema, still posts monthlyIncome in every payload (lines 312-657). Every paymentInfoSchema and checkoutSchema assertion now fails with a generic "Required" instead of exercising the rule it claims to check: 18 failing assertions covering income, routing number, and account number validation. Separately, and still live, schemas.ts:51 now accepts an account number as short as 5 digits, where the tests (and the message text next to the rule) expect an 8-digit floor.

Because nothing runs this file locally by default and nothing runs it in CI at all, a change like this can land, merge, and deploy with zero signal that the field it validates has drifted from what's tested.