StraightSum
Loan options

Security

Last updated: August 2026

The short version

The best security property this site has is that it holds almost nothing. It is a static export: pre-built HTML and JavaScript served from a CDN, with no application server, no database, and no user accounts. There is no store of customer records to breach, because there is no store.

The calculators, the Dashboard, and the Paycheck Planner run entirely in your browser and keep their data on your own device. We cannot see your figures. The one place sensitive information does move is the loan request form, which is operated by an independent third party — described plainly below rather than glossed over.

What we deliberately do not hold

  • No user accounts, passwords, or password hashes
  • No database of applicants or inquiries
  • No Social Security Numbers, bank account numbers, or card numbers
  • No copy of anything you enter into the request form
  • No copy of your Dashboard, Planner, or calculator inputs

This has a consequence worth planning for, and it is not entirely in your favour: because your tool data exists only in your browser, we cannot recover it. Clearing your browser data deletes it permanently. The Dashboard has an Export button for exactly this reason.

Encryption

The site is served over HTTPS only, with TLS terminated at the CDN edge. HTTP Strict Transport Security is sent with a two-year max-age and includeSubDomains, so after your first visit a browser will refuse to connect over plain HTTP even if a link tries to. Data submitted through the request form is encrypted in transit to the provider operating it.

Response headers we send

These are configured in public/_headers. Verify any of them yourself with your browser's network inspector or a header-checking tool — and if one is missing, that is a bug and we would like to hear about it.

One platform caveat: _headers is read by Cloudflare Pages and Netlify. On Vercel, S3, or most other hosts the file is silently ignored and none of the below would be sent. This site runs on Cloudflare Pages, which is why the file is the right mechanism here.

Strict-Transport-Security

max-age=63072000; includeSubDomains

After your first visit, browsers refuse to connect over plain HTTP for two years — including on subdomains, and including if a link tries to.

X-Content-Type-Options

nosniff

Stops a browser guessing that a file is executable script when the server said it is not.

Referrer-Policy

strict-origin-when-cross-origin

Stops the full URL of the page you were reading leaking to third parties. Relevant here because some URLs carry calculator inputs.

X-Frame-Options

SAMEORIGIN

Prevents another site framing ours to trick you into clicking something you cannot see.

Permissions-Policy

camera=(), microphone=(), geolocation=(), payment=(), usb=(), fullscreen=(self), web-share=(self), browsing-topics=(), interest-cohort=()

Nothing on this site needs a camera, a microphone, or your location, so nothing can request them. browsing-topics and interest-cohort are disabled to opt out of interest-based ad profiling.

Content-Security-Policy-Report-Only

policy is evaluated and violations are logged — nothing is blocked

Note the header name. This is REPORT-ONLY, not enforced. See the section below, which explains why and what it does and does not protect you from.

Our Content-Security-Policy is not enforced yet

We send Content-Security-Policy-Report-Only, not Content-Security-Policy. The difference is the whole point: a report-only policy is evaluated by the browser and violations are logged to the console, but nothing is actually blocked. So the policy currently documents an intention rather than enforcing a restriction.

Why. Enforcing it broke the loan request form, which is the one thing on this site that earns money. The form is loaded through a generated script from a third-party provider, and scripts of that generation typically pull further scripts, frames, and beacons from hosts that cannot be enumerated by reading the embed code — you have to observe a complete submission and collect them. Rather than leave the form broken, or leave a policy in place that had already proven wrong, it went back to report-only with the re-enabling procedure written into _headers.

What that means for you. You do not currently have CSP protection against script injection on this site. You do still have X-Content-Type-Options, X-Frame-Options, HSTS, and Permissions-Policy, all enforced. And the site holds no accounts, no passwords, and no personal records, so the value of a successful injection here is unusually low — there is nothing stored to steal.

A second limitation worth stating even once the policy is enforced: it will still include 'unsafe-inline' for scripts. That is not laziness — the framework emits inline hydration scripts and the structured-data blocks are inline, and a statically exported site cannot issue a per-request nonce to authorise them individually. The policy restricts where external scripts, styles, frames, and connections may come from, which is the part that matters against third-party compromise. It does not block inline script outright, and we would rather you knew that than assumed otherwise.

Third-party code, and where our control ends

Two independent providers operate embedded components on this domain. Their infrastructure is theirs, not ours — we cannot patch it, audit it, or answer for it, and naming them is the only way you can make an informed decision about what to enter where.

Loan request form

The loan request form is operated by an independent third-party provider. Information entered into it is transmitted to that provider and to lenders in its network.

https://cdn101.zeroparallel.com

CCPA / CPRA request intake

Privacy requests submitted through the embedded form are processed by an independent third-party provider on our behalf.

https://ccpa.lendyou.com

Vulnerabilities in either provider's own systems should be reported to them directly. They are listed as out of scope in our security.txt for that reason.

One known weakness we are working on. The request form is currently served from this same origin, and its iframe sandbox therefore includes allow-same-origin alongside allow-scripts. Per the HTML specification that combination voids the sandbox, so code inside the frame can in principle reach the browser storage the tools use. Nothing has been observed doing so, and the fix is to serve the form from a separate subdomain, which is planned rather than done. We would rather disclose an open weakness than describe a sandbox that is not in effect.

Responsible disclosure

If you believe you have found a vulnerability, email security@straightsum.com. We acknowledge reports within 24 business hours and aim to resolve confirmed issues within 90 days. We do not operate a paid bounty, and we say so up front rather than letting you find out afterwards. We do credit researchers who want the credit.

In scope

straightsum.com and its subdomains.

Please do not

  • access, modify, or exfiltrate data belonging to anyone else
  • run automated scanning that degrades availability for users
  • submit real personal or financial information while testing
  • engage in social engineering against staff or partners

The machine-readable policy is at /.well-known/security.txt (RFC 9116).

What we cannot promise

No system is completely secure, and this is a small operation rather than a bank. We do not hold SOC 2, we have not commissioned a penetration test, and there is no security team on call. What we have is a small attack surface, a deliberate refusal to store data we do not need, and headers you can verify for yourself in under a minute.

Practical advice that does more for you than any of the above: never pay a fee before a loan is funded, verify a lender on NMLS Consumer Access before you sign, and treat any unsolicited message claiming to be from us about a specific loan application as fraudulent — we have no access to your loan and would never contact you about one.

Related