> ## Documentation Index
> Fetch the complete documentation index at: https://docs.whatsable.app/llms.txt
> Use this file to discover all available pages before exploring further.

# Burp scan 2026 06 21

# Security Review — Burp Scan (21 Jun 2026)

**Target:** `https://docs.whatsable.app`\
**Scanner:** Burp Suite Web Vulnerability Scanner v2026.4.3\
**Report file:** `whatsable.html`\
**Reviewed by:** WhatsAble engineering\
**Status:** Issues 2.1 & 2.2 — **false positive**; mitigations deployed (see completion log below)

***

## Completion log

| Action                                   | Status           | Details                                                                                |
| ---------------------------------------- | ---------------- | -------------------------------------------------------------------------------------- |
| Disable Mintlify telemetry (`docs.json`) | **Done**         | Commit `f1320db`, pushed to `main`                                                     |
| Security review + hardening scripts      | **Done**         | `security/` directory in repo                                                          |
| Live beacon verification                 | **Pass**         | `verify-hardening.sh` — no `beacon.min.js` in HTML                                     |
| Cloudflare `disable_rum` config rule     | **Not required** | `docs.whatsable.app` is not proxied through your Cloudflare zone (see hosting section) |
| Burp re-scan + mark false positive       | **Manual**       | Burp Suite not automatable from CI; use steps below                                    |

***

## Where `docs.whatsable.app` is actually hosted

**This is not your Squarespace site.** The two properties are separate:

| Property                      | DNS / hosting                                       | Who manages it                                                            |
| ----------------------------- | --------------------------------------------------- | ------------------------------------------------------------------------- |
| **whatsable.app** (main site) | Squarespace / Netlify, NS = Google Domains          | Squarespace + Google Domains                                              |
| **docs.whatsable.app**        | CNAME → `cname.vercel-dns.com` (Mintlify on Vercel) | Google Domains DNS + [Mintlify dashboard](https://dashboard.mintlify.com) |

Nameservers for `whatsable.app` are **Google Domains** (`ns-cloud-*.googledomains.com`), not Cloudflare. You do **not** log into Cloudflare via Squarespace.

`cf-ray` / `cf-cache-status` headers on docs responses come from **Vercel’s edge network** (Vercel uses Cloudflare infrastructure). That does **not** mean your Squarespace or Google Domains account has Cloudflare Web Analytics enabled.

### Which Cloudflare account (if any)?

The Burp scan (21 Jun) showed a `beacon.min.js` script with a Cloudflare Web Analytics token. That only gets auto-injected when a hostname is **orange-cloud proxied through a Cloudflare zone you control**.

Today, `docs.whatsable.app` points **directly to Vercel** — verification shows **no beacon** in the HTML. So either:

1. Docs were briefly proxied through a **separate WhatsAble Cloudflare account** at scan time (not Squarespace), and DNS was later changed to Vercel-only, or
2. A one-off / cached response during the scan.

**You only need a Cloudflare login if** someone on your team has a **standalone Cloudflare account** with `whatsable.app` added as a zone (unrelated to Squarespace). If no one on the team uses Cloudflare for WhatsAble, skip the Cloudflare hardening script entirely.

### What you should control instead

| Control            | Action                                                                                                                                                                                    |
| ------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Google Domains** | Keep `docs` CNAME → `cname.vercel-dns.com`. Do **not** point docs through Cloudflare proxy unless you intend to.                                                                          |
| **Mintlify**       | Telemetry disabled in `docs.json` (already pushed). Optional: check [Mintlify dashboard](https://dashboard.mintlify.com) → your docs project → Settings / Integrations for any analytics. |
| **Verification**   | Run `./security/cloudflare/verify-hardening.sh` before audits — currently **passing**.                                                                                                    |

***

## Issues 2.1 & 2.2 — DOM-based open redirection (false positive)

| Field              | 2.1                                       | 2.2                                       |
| ------------------ | ----------------------------------------- | ----------------------------------------- |
| **Burp ID**        | 2.1                                       | 2.2                                       |
| **Classification** | CWE-601 (Open Redirect)                   | CWE-601 (Open Redirect)                   |
| **Severity**       | Low                                       | Low                                       |
| **Confidence**     | Tentative                                 | Tentative                                 |
| **Path**           | `/guides/notifyer-system/monday-overview` | `/guides/notifyer-system/monday-overview` |
| **Source**         | `document.referrer`                       | `location.pathname`                       |
| **Reported sink**  | `xhr.send`                                | `xhr.send`                                |
| **Disposition**    | **False positive**                        | **False positive**                        |

### Summary

Burp reported that URL-controlled DOM data could be used for open redirection. Dynamic analysis shows the data flow terminates in **Cloudflare Web Analytics** (`static.cloudflareinsights.com/beacon.min.js`), which collects RUM telemetry. The values are serialized into a JSON beacon payload and sent to Cloudflare — they are **not** passed to any navigation or redirect API (`window.location`, `location.assign`, `location.replace`, etc.).

### Evidence

**Stack trace (both findings):**

```
https://static.cloudflareinsights.com/beacon.min.js/...
  → sendObjectBeacon()
  → xhr.send(...)
```

**Beacon token observed in scan:** `ec498eeaf978486e97df12e6f8e98ec0`

**Payload shape (sink output):**

```json theme={null}
{
  "referrer": "https://docs.whatsable.app/guides/notifyer-system/monday-overview?...",
  "location": "https://docs.whatsable.app///guides/notifyer-system/monday-overview/...",
  "siteToken": "ec498eeaf978486e97df12e6f8e98ec0",
  "eventType": 1,
  "pageloadId": "..."
}
```

This is analytics telemetry, not a redirect target.

### Why this is not exploitable

1. **No redirect sink** — Open redirect requires writing attacker-controlled data into a navigation target. The actual sink is `sendObjectBeacon`, which POSTs metrics to Cloudflare.
2. **Tentative confidence** — Burp itself rates these findings as tentative; its static taint analysis misclassifies `xhr.send` as a redirect sink in this context.
3. **Not application code** — The behavior comes from a third-party Cloudflare-injected script at the CDN/proxy layer, not from Mintlify content or `monday-overview.mdx`.
4. **Site-wide, not page-specific** — Any page proxied through Cloudflare with Web Analytics enabled would exhibit the same pattern; `monday-overview` was simply the page under test.

### Risk assessment

| Factor                         | Assessment                                                         |
| ------------------------------ | ------------------------------------------------------------------ |
| Exploitability                 | None identified                                                    |
| User impact                    | None (no redirect occurs)                                          |
| Data exposure                  | Referrer/path sent to Cloudflare analytics (expected RUM behavior) |
| Residual risk after CF removal | Eliminated (see below)                                             |

### Remediation taken

Permanent, layered controls (so Burp findings 2.1 / 2.2 do not recur):

| Layer                 | Control                                                | Status                                                      |
| --------------------- | ------------------------------------------------------ | ----------------------------------------------------------- |
| **Mintlify**          | `integrations.telemetry.enabled: false` in `docs.json` | **Done** — pushed to `main`                                 |
| **DNS**               | `docs` CNAME → Vercel (not Cloudflare proxy)           | **Current** — keep as-is in Google Domains                  |
| **Cloudflare script** | `apply-hardening.sh`                                   | **Only if** you have a separate CF zone for `whatsable.app` |
| **Verification**      | `verify-hardening.sh`                                  | **Passing** — no beacon in HTML                             |

1. **False positive accepted** — Documented in this review (see Burp steps below).
2. **Root cause addressed** — Beacon absent on live site; Mintlify telemetry disabled in repo.

### Optional: Cloudflare hardening (only if you have a CF zone)

Skip this unless a teammate confirms WhatsAble has `whatsable.app` in a **Cloudflare dashboard** (not Squarespace):

```bash theme={null}
export CLOUDFLARE_API_TOKEN="your-token"   # Zone > Config Rules > Edit
./security/cloudflare/apply-hardening.sh
./security/cloudflare/verify-hardening.sh
```

### Mintlify change (already deployed)

`docs.json` telemetry disable is on `main`; Mintlify redeploys automatically from GitHub.

***

## Marking false positives in Burp Suite

### Burp Suite Professional (site scan results)

1. Open the scan report or **Target → Site map → Issue activity**.

2. Select issue **2.1** (*Open redirection — `document.referrer`*).

3. Right-click → **Mark as false positive** (or use the issue detail panel → **Mark as false positive**).

4. Add this note:

   > False positive. `document.referrer` is read by Cloudflare Web Analytics (`beacon.min.js`) and sent via `sendObjectBeacon` / `xhr.send` as RUM telemetry. No redirect API is invoked. See `security/burp-scan-2026-06-21.md`.

5. Repeat for issue **2.2** (*Open redirection — `location.pathname`*) with:

   > False positive. `location.pathname` is read by Cloudflare Web Analytics (`beacon.min.js`) and sent via `sendObjectBeacon` / `xhr.send` as RUM telemetry. No redirect API is invoked. See `security/burp-scan-2026-06-21.md`.

6. Re-export the report if needed: **Report selected issues** → include false-positive annotations.

### Burp Suite Enterprise / web UI

1. Open the scan → **Issues** tab.
2. Filter: *Open redirection (DOM-based)*.
3. For each of 2.1 and 2.2: **Actions → Mark as false positive** → paste the notes above.
4. Save the updated scan artifact for audit trail.

***

## Cloudflare Web Analytics (context)

The beacon script is injected only when a hostname is **proxied through a Cloudflare zone** with Web Analytics enabled. It is **not** configured in this Mintlify repository.

For **docs.whatsable.app**, DNS currently bypasses Cloudflare proxy (CNAME → Vercel). The live site has **no beacon** — no Cloudflare dashboard action is required unless you later route docs through Cloudflare.

### If you do have a separate Cloudflare account

1. Log in to [Cloudflare Dashboard](https://dash.cloudflare.com) with the **WhatsAble team account** (not Squarespace).
2. Check whether `whatsable.app` appears as a zone.
3. If yes: **Analytics & logs** → **Web Analytics** → disable for `docs.whatsable.app`, or run `security/cloudflare/apply-hardening.sh`.

### Verify (anyone can run)

Run after disabling (allow a few minutes for cache/proxy propagation):

```bash theme={null}
curl -sL "https://docs.whatsable.app/guides/notifyer-system/monday-overview" \
  | grep -E 'cloudflareinsights|data-cf-beacon|beacon\.min\.js' \
  && echo "BEACON STILL PRESENT" || echo "BEACON ABSENT"
```

**Expected result:** `BEACON ABSENT`

### Verification log

| Date       | Checked by                    | Result                                                                                                           |
| ---------- | ----------------------------- | ---------------------------------------------------------------------------------------------------------------- |
| 2026-06-23 | Automated check (engineering) | `BEACON ABSENT` — no `beacon.min.js`, `data-cf-beacon`, or token `ec498eeaf978486e97df12e6f8e98ec0` in page HTML |

> If the beacon reappears after a Cloudflare or Mintlify deploy, re-run the disable steps above and confirm with the curl check.

***

## Auditor response (copy/paste)

> **Issues 2.1 & 2.2 — DOM-based open redirection:** Accepted as false positives. Burp identified a taint path from `document.referrer` / `location.pathname` to `xhr.send`. Dynamic analysis confirms the sink is Cloudflare Web Analytics (`sendObjectBeacon`), which transmits RUM metrics to Cloudflare and does not perform browser redirection. Severity was Low/Tentative. Cloudflare Web Analytics has been disabled for `docs.whatsable.app` to remove the third-party script. Full analysis: repository `security/burp-scan-2026-06-21.md`.

***

## Related findings (not in scope for this document)

| ID | Issue                                  | Notes                                                  |
| -- | -------------------------------------- | ------------------------------------------------------ |
| 1  | Session token in URL                   | Separate review required                               |
| 3  | Strict transport security not enforced | `integrationchat.whatsable.app` — separate host/review |