Sample penetration testing report for a fictional app

• 01Project details
• 02Assessment method
• 03Safety constraints
• 04Evidence labels
• 05Executive summary
• 06Findings at a glance
• 07Reproduction environment
• 08Findings F-01 to F-09
• 09Controls that held
• 10Remediation plan
• 11Limitations and open questions
• 12Evidence index

Project details#

The report covers a grey-box assessment of the Harbor Notes web application and JSON API.

Scope and assets#

We tested only the assets marked Yes.

Features reached through the in-scope hosts: workspaces, notes, sharing links, file attachments, invitations, billing plans, a search endpoint and the admin panel.

Severity scale#

We use a four-level scale and add no CVSS vectors by default. If your program needs CVSS, say so during scoping and we agree the method in writing.

We set each level from the effect we proved. When a control changes our view, we change the level and say so in the finding.

Assessment method#

We tested the application as an authenticated user with known roles. We started from the client JavaScript bundle and the observed API traffic, then tested each object type and function against the roles.

We used these methods:

1. Direct HTTP requests: we sent requests with an HTTP client, with and without credentials, and saved each request and response with a timestamp.
2. Browser-observed tests: we checked cross-site request forgery and script injection in a real Chromium browser. A script that runs in a browser is stronger proof than a payload that appears in a response body.
3. Client bundle review: we read the JavaScript bundles to list API routes, feature flags and client-side role checks that the server may not repeat.
4. Differential comparison: we sent the same request as an anonymous caller, as each role in tenant A and as each role in tenant B, then compared status codes and bodies.
5. Read-back from a second account: when a request changed data, we read the record back through a different session. A "200 OK" or {"success": true} is not proof of an effect.
6. Controls: we ran control requests next to each exploit request: nonexistent identifiers, wrong record types, unsigned or wrongly signed cookies, another account's token, and anonymous against signed-in comparisons.

Safety constraints#

Destructive proofs used only test-owned accounts and records. Each record we created carried the marker EXC-TEST in its title, so the client can find and remove it.

Evidence labels#

Every finding carries one label. The label tells you how strongly the evidence supports the claim.

Open questions go to the section "Limitations and open questions", never into confirmed impact.

Executive summary#

We found nine issues in Harbor Notes: one Critical, three High, three Medium and two Low. One issue allows any signed-in user to download another tenant's exported workspace. We proved this with two test tenants we own.

Counts come from the findings table, as of the report date 2026-11-09. One finding (F-08) started as High and ended as Low after a control showed our first reading was wrong. We kept it in the report to show the change.

The root causes fall into three groups. Object access checks are missing on some routes (F-01, F-04). Browser protections are missing or incomplete (F-02, F-03, F-07). Abuse limits and lifecycle rules are missing (F-05, F-06). The two Low findings are hardening items.

Priority actions#

1. Add a workspace ownership check to the export download route (F-01). Until it ships, disable the route or block cross-tenant reads at the API gateway.
2. Encode note titles where they are rendered, and add a Content Security Policy (F-02).
3. Bind the login flow to a CSRF token and set SameSite on the session cookie (F-03).
4. Ignore the role field from the client on invitation requests (F-04).
5. Add per-account and per-address limits to password reset (F-05).

Actions 1 to 4 close the High and Critical findings. Action 5 is the first Medium item and uses a standard control.

Findings at a glance#

The table lists every finding with its severity, current status and evidence label. Status is the state at report delivery. No fixes have been verified yet.

Reproduction environment#

All requests used these values, so you can reproduce each finding with the same setup.

F-01: Cross-tenant export through predictable export IDs#

Critical Evidence label: Observed

Description#

Harbor Notes lets a workspace owner export all notes and attachments as a ZIP archive. The app creates an export job and then downloads the result from GET /v1/exports/{export_id}/download.

Export IDs are sequential integers with a prefix, for example exp_000412, then exp_000413. The download route checks that the caller has a valid token. It does not check that the caller belongs to the workspace that owns the export.

The route that lists exports for a workspace (GET /v1/workspaces/{id}/exports) does check membership. The download route does not repeat the check.

Impact#

Any signed-in user, in any tenant, can download the full export of any other tenant. The attacker needs no special role, and a free-plan account is enough. The attacker can walk the ID range to collect exports across the platform.

An export holds every note in the workspace, the member list and all attachments. Together these make up the full content of a customer account. We rate this Critical because it needs no chain, no user action and no privilege.

Verified results#

We created an export in tenant A, then fetched it with a token for a member of tenant B. Tenant B received the archive that belongs to tenant A.

The marker note was written by tenant A and never shared with tenant B. Its presence in the archive that member-b downloaded is the read-back proof. Evidence: ev-01-export-create.json, ev-02-export-xtenant.http, ev-03-readback.json.

We tested only IDs we created, did not walk the ID range, and opened no export we did not create.

Reproduction#

Step 1. Tenant A creates an export.

POST /v1/workspaces/ws_test_A/exports HTTP/1.1
Host: api.harbor-notes.example
Authorization: Bearer $TOKEN_OWNER_A
Content-Type: application/json

{"include_attachments": true}

HTTP/1.1 202 Accepted
Content-Type: application/json

{"id": "exp_000412", "workspace_id": "ws_test_A", "status": "ready"}

Step 2. A member of tenant B requests the same export.

GET /v1/exports/exp_000412/download HTTP/1.1
Host: api.harbor-notes.example
Authorization: Bearer $TOKEN_MEMBER_B

HTTP/1.1 200 OK
Content-Type: application/zip
Content-Disposition: attachment; filename="ws_test_A-export.zip"
Content-Length: 2318

The filename value names tenant A's workspace, so the response itself shows the cross-tenant effect.

Controls#

The control with the list route shows that a membership check exists in the codebase. The download route is missing it.

Remediation#

Check workspace membership in the download handler, after the lookup and before any file is returned. Return 404 for exports the caller may not read, so the response does not confirm that an ID exists.

// GET /v1/exports/:exportId/download
const exp = await db.exports.findById(req.params.exportId);
if (!exp) return res.status(404).json({ error: "not_found" });

const member = await db.memberships.find({
  workspaceId: exp.workspaceId,
  userId: req.user.id,
});
if (!member || !can(member.role, "workspace:export")) {
  return res.status(404).json({ error: "not_found" });
}
return streamExport(exp, res);

Also replace sequential IDs with random 128-bit identifiers. Random IDs make enumeration harder but do not replace the access check. Add an automated test that requests each object route with a token from another tenant and expects 404. Review other routes that take an object ID in the path for the same missing check.

F-02: Stored XSS in shared note titles#

High Evidence label: Browser-observed

Description#

When a user shares a note, the "Shared with me" list shows the note title to each recipient. The React app renders the title with dangerouslySetInnerHTML in the list item component. The API stores the title as typed and does not encode it.

A title that contains HTML runs in the recipient's browser when the recipient opens the "Shared with me" page.

Impact#

An attacker with any account can run script in the app origin as the recipient. The script can read data that the recipient's session can read, and it can call the API as the recipient. If the recipient is a workspace owner, the script can create invitations or exports in their name.

The attacker needs one user action: the recipient must open the list. The recipient does not need to open the note. We rate this High and not Critical because it needs a user action and a sharing relationship.

Verified results#

We shared a note from member-a to owner-b (both test accounts). The title contained a harmless marker script. When we opened "Shared with me" as owner-b in Chromium, the script ran in the origin https://app.harbor-notes.example and wrote a marker into the page.

The editor encodes the title and the list does not, so the flaw is in one component. Evidence: ev-04-xss-browser.png, ev-05-xss-console.json.

The payload used only the marker and the /v1/me read. We did not send data to any outside host.

Reproduction#

PATCH /v1/notes/note_test_0031 HTTP/1.1
Host: api.harbor-notes.example
Authorization: Bearer $TOKEN_MEMBER_A
Content-Type: application/json

{"title": "EXC-TEST <img src=x onerror=\"document.body.dataset.exc='fired'\">"}

HTTP/1.1 200 OK
Content-Type: application/json

{"id": "note_test_0031", "title": "EXC-TEST <img src=x onerror=\"document.body.dataset.exc='fired'\">"}

Then share the note with owner-b and open /shared as owner-b in Chromium. The onerror handler sets document.body.dataset.exc, and the test reads it with the browser developer tools.

Controls#

Remediation#

Remove dangerouslySetInnerHTML from the list component and render the title as a React text node.

// SharedNoteItem.jsx
- <span dangerouslySetInnerHTML={ { __html: note.title } } />
+ <span>{note.title}</span>

Add a Content Security Policy that blocks inline script, for example script-src 'self'; object-src 'none'; base-uri 'none'. A policy limits the effect of the next injection bug. Add a lint rule that fails the build on dangerouslySetInnerHTML without an approved sanitizer. Search the other list components for the same pattern.

F-03: Login CSRF on the sign-in endpoint#

High Evidence label: Browser-observed

Description#

POST /v1/auth/login accepts a form-encoded body and sets the session cookie. It has no CSRF token and no Origin check. The hn_session cookie is set with SameSite=None.

A page on another site can submit a login form that signs the victim's browser in to the attacker's account.

Impact#

The victim keeps using Harbor Notes without noticing that the session belongs to the attacker's account. Notes and attachments that the victim writes then go to the attacker. This is a data-loss path for users who do not notice the change of account.

We rate this High because the effect is a silent data transfer and users may paste sensitive text into notes. We did not prove a path to account takeover.

Verified results#

We hosted a test page on a separate origin we control. The page auto-submitted a login form with the credentials of member-b. We opened the page in a Chromium profile that held no session.

Evidence: ev-06-csrf-login.html, ev-07-csrf-browser.png.

Reproduction#

POST /v1/auth/login HTTP/1.1
Host: api.harbor-notes.example
Origin: https://csrf-test.example
Content-Type: application/x-www-form-urlencoded

email=member-b%40test.harbor-notes.example&password=<test-owned password>

HTTP/1.1 302 Found
Location: https://app.harbor-notes.example/
Set-Cookie: hn_session=<redacted>; Path=/; Secure; HttpOnly; SameSite=None

Controls#

The CSRF control on POST /v1/notes shows that state-changing API routes are protected. Only the sign-in route is open.

Remediation#

Set SameSite=Lax on the session cookie unless a cross-site flow needs None. Check the Origin header on the login route and reject any origin that is not on the allow list. Add a double-submit CSRF token to the login form.

const ALLOWED = new Set(["https://app.harbor-notes.example"]);

app.post("/v1/auth/login", (req, res, next) => {
  const origin = req.get("Origin");
  if (!origin || !ALLOWED.has(origin)) {
    return res.status(403).json({ error: "bad_origin" });
  }
  next();
});

After login, show the signed-in account name in the app header, so users can see which account they use.

F-04: Invitation endpoint accepts a client-chosen role#

High Evidence label: Observed

A workspace member can invite a user as admin. POST /v1/workspaces/{id}/invitations reads the role field from the request body and does not compare it to the caller's role. The member-a account invited a second test account as admin. After acceptance, GET /v1/workspaces/ws_test_A/members as that account showed role admin, and the account could change billing settings. Evidence: ev-08-invite-role.http.

Controls: the same request with role: "owner" returned 400, a request for a nonexistent workspace returned 404, and the web UI hides the role selector from members. The UI check is client-side only. Fix: derive the allowed roles from the caller's role on the server, and reject any role that is higher than the caller's own role.

F-05: No rate limit on password reset#

Medium Evidence label: Observed

Description#

POST /v1/auth/password-reset sends a reset email to the address in the request. The route has no limit by address, by IP or by account. It returns the same response for known and unknown addresses.

Impact#

An attacker can send many reset emails to one user. This floods the user's inbox and costs Harbor Notes email sending fees. It can also hide a real security email among many others. The route does not reveal whether an account exists.

We did not find a way to guess or bypass the reset token. We rate this Medium because the effect is nuisance and cost, and it gives no access.

Verified results#

We ran a bounded test against one test account (member-a) with a test inbox. We sent 60 requests in 90 seconds from one IP address and stopped there.

All 60 emails arrived, so the server applied no limit in that window. Evidence: ev-09-reset-burst.json, ev-10-reset-inbox.json.

We chose 60 because it is large enough to show that no short-window limit exists and small enough to stay within the safety limit in this report. We did not test higher counts.

Reproduction#

POST /v1/auth/password-reset HTTP/1.1
Host: api.harbor-notes.example
Content-Type: application/json

{"email": "member-a@test.harbor-notes.example"}

HTTP/1.1 202 Accepted
Content-Type: application/json

{"status": "if_account_exists_email_sent"}

Repeat the request 60 times with a test-owned address and count the 202 responses.

Controls#

Remediation#

Limit requests by address and by IP. A common starting point is 3 requests per address per hour and 20 per IP per hour. Return the same 202 response when a limit applies, so the limit does not leak account state.

const resetLimiter = rateLimit({
  windowMs: 60 * 60 * 1000,
  limit: 3,
  keyGenerator: (req) => req.body.email?.toLowerCase() ?? req.ip,
  handler: (req, res) =>
    res.status(202).json({ status: "if_account_exists_email_sent" }),
});
app.post("/v1/auth/password-reset", resetLimiter, resetHandler);

Add an alert for a high rate of reset requests, and consider a CAPTCHA after repeated requests.

F-06: Share links survive when a note becomes private#

Medium Evidence label: Observed

When an owner sets a note to private, the public share link https://app.harbor-notes.example/s/{token} still returns the note. We created a link for a test note, switched the note to private in the UI (the UI showed "Private"), and requested the link as an anonymous caller. The response was 200 with the note body. The link stayed valid after we also removed the sharing record in the UI. A fresh link for the same note had a different token, so the old one was never revoked. Evidence: ev-11-share-after-private.http.

Controls: a link with one character changed returned 404, tokens were 22 random characters, and deleting the note made the link return 404. Fix: when a note changes to private, delete or revoke its share tokens in the same database transaction. Add an optional expiry date for share links, and show the owner a list of active links.

F-07: Attachments served inline with the uploaded content type#

Medium Evidence label: Browser-observed

The download route GET /v1/files/{id} returns the file with the content type chosen at upload and with Content-Disposition: inline. It sets no X-Content-Type-Options: nosniff header. An SVG file that contained a marker script ran in Chromium when we opened the file URL directly.

The script ran on the API origin api.harbor-notes.example, not on the app origin. The session cookie is not sent to the API host, and the API needs a bearer token that lives in app memory. So the script could not read the token. This control is why we rate the finding Medium and not High. If the two hosts ever share a registrable cookie scope or a token store, the finding becomes High.

The upload test used 3 files under 4 KB, which we deleted. Evidence: ev-12-svg-inline.png. Fix: serve user files from a separate sandbox domain, send Content-Disposition: attachment for any type other than a short allow list of images, set X-Content-Type-Options: nosniff, and add Content-Security-Policy: sandbox on file responses.

F-08: Audit log readable by the member role#

Low Evidence label: Observed. Downgraded from High.

Description#

GET /v1/admin/audit-log returned 200 for member-a. The route sits under the admin prefix, so we first recorded it as High: an admin function open to the lowest role.

What changed our view#

We ran the controls after the first observation. They showed that our first reading was wrong.

The route is a read-only view of events that members can already see. The only extra data is the IP address of other members in the same workspace. We changed the level from High to Low. Evidence: ev-13-auditlog-member.http, ev-14-auditlog-controls.http.

Remediation#

Remove ip_address from the member view, or restrict the route to admin and owner roles. Name the route outside the /admin prefix if it is meant for all members, so route names match their access rules.

F-09: Search errors disclose internal index names#

Low Evidence label: Observed

GET /v1/search?q= with a malformed filter value returns a 500 response whose body includes the internal index name (notes_v7_tenant_shard_3) and the search library version. The text helps an attacker plan later tests. It gives no access to data. We tested with three malformed values on test data, and a valid query returned normal results with tenant scoping intact. A cross-tenant query with a workspace_id filter for tenant B returned only tenant A results. Evidence: ev-15-search-error.http. Fix: catch search errors, log the detail on the server, and return a generic error with a request ID.

Controls that held#

These protections worked under test. Fixes must not remove them.

We list these because the fixes for F-01 and F-04 touch the same authorization code. A regression test for each control keeps the fix from weakening it.

Remediation plan#

The plan orders actions by the risk they remove. Owners are placeholders. Effort is S (under one day of work), M (a few days) or L (more than a week).

After the fixes ship, ask for a retest of F-01 to F-04. A retest uses the same requests and the same controls.

Limitations and open questions#

The points here are limits of this assessment, not confirmed findings.

• Time-boxed: Testing ran for five days against a fixed scope. A lack of findings in an area does not show that the area has no issues.
• Grey-box accounts: We tested with the roles we were given. Roles that the client adds later were not tested.
• Unproven chain (inferred): F-02 and F-04 might combine: script in an owner's session could send an invitation with a chosen role. We did not run this chain, so we do not count it as impact.
• Open question on export history. We do not know whether other tenants' exports were downloaded before this test. The client should check access logs for GET /v1/exports/*/download where the caller's workspace differs from the export's workspace.
• Open question on F-07 and cookie scope. The client should confirm that the app and API hosts will never share a cookie scope.
• Not tested: Third-party checkout pages, the email provider, load behavior, and the mobile apps.

Evidence index#

Each item is a saved request, response, screenshot or script output with a UTC timestamp. The hashes below are placeholders for this demonstration. In a real report, the SHA-256 manifest lets you check that a file has not changed.

Appendix: reproduction scripts#

The proof-of-concept scripts ship with the report as files, one per finding. They are read-only where possible and take identifiers as arguments, for example repro/f01_readback.sh ws_test_A exp_000412. Run them only with authorization from the system owner and with test-owned identifiers.

This page is a demonstration. The methodology page describes how we work. To ask about a test of your own application, contact us. For a small, scoped test at no cost, see the free pentest pilot.