Seatrial checks itself

Our own code and live website, checked on each release. Findings stay visible, including the ones we still need to fix. Newest runs first.

Only public reads. No sign-in, forms, payments or messages. Coverage gaps are not passes.

Release check · 11/2/2026, 5:22:36 AM UTC

gtsbahamas/shipsafe-web · https://seatrial.io · revision 9a8b7a48

Website, exposure and versions: ran — 11 findings and notes
Open redirects: ran — Existing URL scanner; GET only, outside redirects never followed. Individual coverage notes apply.
Safe confirmation and combined risks: ran — 2 proof attempts, 0 combined risks
Agent wiring and prompt injection review: ran — 0 static findings. Live agent conversations are not run: they require POST/sign-in, beyond this read-only target.
OWASP benchmark: ran — OWASP Juice Shop 20.3.0: found 0 of 116 documented issues (0%), missed 116; 0 of 7 that Seatrial has a check for; confirmed extras 6 of 8; false alarms 0 of 9 scored findings. Isolated owned Juice Shop container; not a score for our live site.

Coverage and proof

Public GET/HEAD only. No sign-in, submitted forms, active agent conversations, customer sites or customer repositories.
Mail/domain registry checks are not run: they contact outside services. Database hosts, OPTIONS and Convex POST queries are refused.
Exposure/version assessment uses the scanner’s bundled advisory baseline when current feed storage cannot be read.
Refused by self-target scope: GET https://seatrial.io (action route)

0 combined risks; 2 proof steps recorded.

{
  "chains": [],
  "proof": [
    {
      "ruleId": "EXPOSURE-VERSION-UNKNOWN",
      "host": "seatrial.io",
      "path": "/",
      "at": "2026-11-02T05:22:42.752Z",
      "outcome": "not-run",
      "detail": "finding carries no version string to confirm"
    },
    {
      "ruleId": "EXPOSURE-VERSION-OK",
      "host": "seatrial.io",
      "path": "/",
      "at": "2026-11-02T05:22:42.904Z",
      "outcome": "not-confirmed",
      "detail": "Re-read the response to confirm version 16.4.3; it was not present, so the version could not be confirmed. — claimed=16.4.3 not observed in server/x-powered-by or body head"
    }
  ]
}

11 findings and coverage notes.

MEDIUM · Your pages have no backstop if a malicious script sneaks in.

This protection does not stop the break-in itself; it limits the damage when one happens. Right now that safety net is missing.

Evidence and fix prompt · HEADER-CSP-UNSAFE-INLINE-STYLE

CSP allows 'unsafe-inline' styles

content-security-policy: default-src 'self'; script-src 'self' 'nonce-MmU4NjM5NzAtYzM2Ny00ZjY1LWFmYTMtYzc2MDEwYTY5NTM5' 'strict-dynamic'; style-src 'self' 'unsafe-inline' https://fonts.googleapis.com…

A security scan of this app found the issue below. Investigate and fix it.

## Finding
- Title: CSP allows 'unsafe-inline' styles
- Severity: medium
- Rule: HEADER-CSP-UNSAFE-INLINE-STYLE
- Area: headers
- Observed at path: /
- Header involved: Content-Security-Policy

## What the scanner recorded
```
content-security-policy: default-src 'self'; script-src 'self' 'nonce-MmU4NjM5NzAtYzM2Ny00ZjY1LWFmYTMtYzc2MDEwYTY5NTM5' 'strict-dynamic'; style-src 'self' 'unsafe-inline' https://fonts.googleapis.com…
```

## What the scanner saw
Your Content-Security-Policy includes 'unsafe-inline' in style-src. Injected CSS runs — this does not execute scripts, but it is not harmless either.

## Why it matters
An attacker who can inject markup can restyle the page (fake login overlays, hidden/moved buttons) and use CSS selector tricks to leak on-page data such as CSRF tokens. Script injection is a separate, higher-severity question governed by script-src.

## Suggested direction
Move inline styles into external stylesheets, then remove 'unsafe-inline' from style-src. Note: frameworks that render style attributes (e.g. React style props) require 'unsafe-inline' — CSP nonces never authorize style ATTRIBUTES, only <style> elements — so this is commonly an accepted, documented risk until inline styles are migrated.

## Rules for this fix
1. Reproduce first. Confirm the issue actually exists before changing anything (run the reproduce command above when there is one). If it does not reproduce, say so and stop — do not "fix" a finding you cannot confirm.
2. Make the smallest change that resolves it. Do not refactor unrelated code.
3. Never weaken or remove an existing security check to make this finding go away.
4. If the real fix belongs in hosting or platform configuration rather than code, say exactly what to change and where, instead of forcing a code change.
5. When you are done, explain what you changed and why in one short paragraph a non-developer can understand.

LOW · Cross-Origin-Embedder-Policy is missing or too open

Without COEP, the browser cannot enable crossOriginIsolated features (SharedArrayBuffer, precise performance.now()). It also leaves embedded cross-origin resources without the extra credentials-stripping the spec provides.

Evidence and fix prompt · HEADER-COEP-MISSING

Cross-Origin-Embedder-Policy is missing or too open

A security scan of this app found the issue below. Investigate and fix it.

## Finding
- Title: Cross-Origin-Embedder-Policy is missing or too open
- Severity: low
- Rule: HEADER-COEP-MISSING
- Area: headers
- Observed at path: /
- Header involved: Cross-Origin-Embedder-Policy

## What the scanner saw
No Cross-Origin-Embedder-Policy header was returned.

## Why it matters
Without COEP, the browser cannot enable crossOriginIsolated features (SharedArrayBuffer, precise performance.now()). It also leaves embedded cross-origin resources without the extra credentials-stripping the spec provides.

## Suggested direction
Add `Cross-Origin-Embedder-Policy: require-corp`. Third-party images/scripts you embed will need their own CORP or CORS opt-in; `credentialless` is an easier migration path.

## Rules for this fix
1. Reproduce first. Confirm the issue actually exists before changing anything (run the reproduce command above when there is one). If it does not reproduce, say so and stop — do not "fix" a finding you cannot confirm.
2. Make the smallest change that resolves it. Do not refactor unrelated code.
3. Never weaken or remove an existing security check to make this finding go away.
4. If the real fix belongs in hosting or platform configuration rather than code, say exactly what to change and where, instead of forcing a code change.
5. When you are done, explain what you changed and why in one short paragraph a non-developer can understand.

INFO · No reporting endpoints configured

You will never see CSP violations, deprecation reports, or intervention reports in production. Debugging CSP is much harder without this.

Evidence and fix prompt · HEADER-REPORT-TO-MISSING

No reporting endpoints configured

A security scan of this app found the issue below. Investigate and fix it.

## Finding
- Title: No reporting endpoints configured
- Severity: info
- Rule: HEADER-REPORT-TO-MISSING
- Area: reporting
- Observed at path: /
- Header involved: Reporting-Endpoints

## What the scanner saw
Neither `Report-To` nor `Reporting-Endpoints` header is set. CSP `report-uri` and `report-to` directives will silently drop reports.

## Why it matters
You will never see CSP violations, deprecation reports, or intervention reports in production. Debugging CSP is much harder without this.

## Suggested direction
Add `Reporting-Endpoints: default="https://your-endpoint/report"` and wire your CSP `report-to default` to it. Services like report-uri.com or Sentry handle the receiving side.

## Rules for this fix
1. Reproduce first. Confirm the issue actually exists before changing anything (run the reproduce command above when there is one). If it does not reproduce, say so and stop — do not "fix" a finding you cannot confirm.
2. Make the smallest change that resolves it. Do not refactor unrelated code.
3. Never weaken or remove an existing security check to make this finding go away.
4. If the real fix belongs in hosting or platform configuration rather than code, say exactly what to change and where, instead of forcing a code change.
5. When you are done, explain what you changed and why in one short paragraph a non-developer can understand.

INFO · We could not see which server software version you run. That is not the same as safe.

Hidden versions can still be old ones. Checking the version on the server, or letting us read what your code declares, tells you for sure.

Evidence and fix prompt · EXPOSURE-VERSION-UNKNOWN

UNKNOWN: Server software (Server and X-Powered-By headers)

No software version in the Server or X-Powered-By headers.

A security scan of this app found the issue below. Investigate and fix it.

## Finding
- Title: UNKNOWN: Server software (Server and X-Powered-By headers)
- Severity: info
- Rule: EXPOSURE-VERSION-UNKNOWN
- Area: software-versions
- Observed at path: /
- Header involved: Server and X-Powered-By

## What the scanner recorded
```
No software version in the Server or X-Powered-By headers.
```

## What the scanner saw
The site does not say which server software or version it runs, so its headers cannot show whether it is exposed.

## Why it matters
Nobody can tell from here whether this is exposed. UNKNOWN is not safe; it means the check could not see.

## Suggested direction
UNKNOWN is not the same as safe: it means the version could not be seen. To find out, connect the repo so ShipSafe can read what it declares (composer.json, Dockerfile, platform files), or run `php -v` (or your runtime's version command) on the server.

INFO · Your website’s framework version has no known serious holes today.

We re-check automatically when new security advisories come out.

Evidence and fix prompt · EXPOSURE-VERSION-OK

OK: Next.js 16.4.3 (Next.js runtime in /_next/static/immutable/chunks/0pwm8dm3kmu-c.js)

/_next/static/immutable/chunks/0pwm8dm3kmu-c.js: …{console.error(e)}).then(()=>{n()}):n()}window.next={version:"16.4.3",appDir:!0},("function"==typeof n.defaul…

A security scan of this app found the issue below. Investigate and fix it.

## Finding
- Title: OK: Next.js 16.4.3 (Next.js runtime in /_next/static/immutable/chunks/0pwm8dm3kmu-c.js)
- Severity: info
- Rule: EXPOSURE-VERSION-OK
- Area: software-versions
- Observed at path: /

## What the scanner recorded
```
/_next/static/immutable/chunks/0pwm8dm3kmu-c.js: …{console.error(e)}).then(()=>{n()}):n()}window.next={version:"16.4.3",appDir:!0},("function"==typeof n.defaul…
```

## What the scanner saw
Next.js 16.4.3 (Next.js runtime in /_next/static/immutable/chunks/0pwm8dm3kmu-c.js) is on a supported branch with no known vulnerable range covering it.

## Why it matters
No known exposure for this version today.

## Suggested direction
Nothing to do now. ShipSafe re-checks when new advisories land.

## Rules for this fix
1. Reproduce first. Confirm the issue actually exists before changing anything (run the reproduce command above when there is one). If it does not reproduce, say so and stop — do not "fix" a finding you cannot confirm.
2. Make the smallest change that resolves it. Do not refactor unrelated code.
3. Never weaken or remove an existing security check to make this finding go away.
4. If the real fix belongs in hosting or platform configuration rather than code, say exactly what to change and where, instead of forcing a code change.
5. When you are done, explain what you changed and why in one short paragraph a non-developer can understand.

INFO · Traffic between your users and your app may not always be encrypted.

On open Wi-Fi, unencrypted traffic can be read or altered by whoever runs the network. Browsers also warn users away from sites that get this wrong.

Evidence and fix prompt · TLS-ISSUER

TLS issuer: Let's Encrypt

issuer: Let's Encrypt
notAfter: Jan 19 22:40:26 2027 GMT

A security scan of this app found the issue below. Investigate and fix it.

## Finding
- Title: TLS issuer: Let's Encrypt
- Severity: info
- Rule: TLS-ISSUER
- Area: tls

## What the scanner recorded
```
issuer: Let's Encrypt
notAfter: Jan 19 22:40:26 2027 GMT
```

## What the scanner saw
Certificate issued by Let's Encrypt.

## Why it matters
Informational only.

## Rules for this fix
1. Reproduce first. Confirm the issue actually exists before changing anything (run the reproduce command above when there is one). If it does not reproduce, say so and stop — do not "fix" a finding you cannot confirm.
2. Make the smallest change that resolves it. Do not refactor unrelated code.
3. Never weaken or remove an existing security check to make this finding go away.
4. If the real fix belongs in hosting or platform configuration rather than code, say exactly what to change and where, instead of forcing a code change.
5. When you are done, explain what you changed and why in one short paragraph a non-developer can understand.

INFO · Traffic between your users and your app may not always be encrypted.

On open Wi-Fi, unencrypted traffic can be read or altered by whoever runs the network. Browsers also warn users away from sites that get this wrong.

Evidence and fix prompt · TLS-CHAIN-DEPTH

TLS certificate chain length: 3

chain length: 3

A security scan of this app found the issue below. Investigate and fix it.

## Finding
- Title: TLS certificate chain length: 3
- Severity: info
- Rule: TLS-CHAIN-DEPTH
- Area: tls

## What the scanner recorded
```
chain length: 3
```

## What the scanner saw
The certificate chain presented by the server is 3 certificate(s) long before the root store takes over.

## Why it matters
Informational only. A typical web cert is depth 2 (leaf + intermediate). Deeper chains add latency on new connections because each intermediate adds bytes to the handshake.

## Rules for this fix
1. Reproduce first. Confirm the issue actually exists before changing anything (run the reproduce command above when there is one). If it does not reproduce, say so and stop — do not "fix" a finding you cannot confirm.
2. Make the smallest change that resolves it. Do not refactor unrelated code.
3. Never weaken or remove an existing security check to make this finding go away.
4. If the real fix belongs in hosting or platform configuration rather than code, say exactly what to change and where, instead of forcing a code change.
5. When you are done, explain what you changed and why in one short paragraph a non-developer can understand.

INFO · Traffic between your users and your app may not always be encrypted.

On open Wi-Fi, unencrypted traffic can be read or altered by whoever runs the network. Browsers also warn users away from sites that get this wrong.

Evidence and fix prompt · TLS-HSTS-PRELOAD-NOT-SUBMITTED

HSTS header is preload-ready but domain is not in the preload list

strict-transport-security: max-age=63072000; includeSubDomains; preload

A security scan of this app found the issue below. Investigate and fix it.

## Finding
- Title: HSTS header is preload-ready but domain is not in the preload list
- Severity: info
- Rule: TLS-HSTS-PRELOAD-NOT-SUBMITTED
- Area: tls
- Observed at path: /
- Header involved: Strict-Transport-Security

## What the scanner recorded
```
strict-transport-security: max-age=63072000; includeSubDomains; preload
```

## What the scanner saw
Your HSTS header is fully-specified (max-age ≥ 1 year, includeSubDomains, preload), but `seatrial.io` was not found in our bundled snapshot of Chrome's HSTS preload list. Note that our snapshot is a small curated subset — the authoritative check is at hstspreload.org.

## Why it matters
Minor — without preload submission, the first visit on a new network is still cleartext-eligible for users who haven't visited before.

## Suggested direction
Submit your domain at https://hstspreload.org. Note that preload is a one-way door: removal takes months.

INFO · We could not check this part, so it is not known to be safe.

The scan did not get the answer it needed. This is a gap in what we saw, not a pass. Running the scan again usually fills it.

Evidence and fix prompt · SCAN-PARTIALLY-BLOCKED-BY-FIREWALL

Scan coverage reduced — Vercel challenged part of it

JavaScript bundles: 8 of 10 answered by Vercel challenge page
Common-path probes: 18 of 30 answered by Vercel challenge page
body is the "Vercel Security Checkpoint" page

A security scan of this app found the issue below. Investigate and fix it.

## Finding
- Title: Scan coverage reduced — Vercel challenged part of it
- Severity: info
- Rule: SCAN-PARTIALLY-BLOCKED-BY-FIREWALL
- Area: coverage
- Observed at path: /

## What the scanner recorded
```
JavaScript bundles: 8 of 10 answered by Vercel challenge page
Common-path probes: 18 of 30 answered by Vercel challenge page
body is the "Vercel Security Checkpoint" page
```

## What the scanner saw
The front page answered normally, but Vercel challenge page intervened on later requests. JavaScript bundles: 8 of 10 answered by Vercel challenge page. Common-path probes: 18 of 30 answered by Vercel challenge page. Endpoint discovery from JavaScript found nothing because it never saw the JavaScript. Endpoint rows marked forbidden (403) with a firewall note were answered by the firewall, not the application; they are not evidence those paths exist.

## Why it matters
The endpoint inventory and the exposure checks are incomplete. A missing finding here means "not assessed", not "not present".

## Suggested direction
If you own this site, allow the scanner's User-Agent ("ShipSafe-Sentinel/0.1 (+https://shipsafe-web-eight.vercel.app)") through the firewall, or exempt it from the bot challenge, then re-run. If you are scanning someone else's site, ask them to do the same. Nothing in this report should be read as a pass until the scanner can reach the application.

INFO · We could not check this part, so it is not known to be safe.

The scan did not get the answer it needed. This is a gap in what we saw, not a pass. Running the scan again usually fills it.

Evidence and fix prompt · DATA-ACCESS-NOT-ASSESSED

Some data-access checks could not run

Cross-site sign-in and response checks on /api/: answered by Vercel challenge page, not the site

A security scan of this app found the issue below. Investigate and fix it.

## Finding
- Title: Some data-access checks could not run
- Severity: info
- Rule: DATA-ACCESS-NOT-ASSESSED
- Area: coverage

## What the scanner recorded
```
Cross-site sign-in and response checks on /api/: answered by Vercel challenge page, not the site
```

## What the scanner saw
These checks did not get an answer, so the report says nothing about them: Cross-site sign-in and response checks on /api/: answered by Vercel challenge page, not the site.

## Why it matters
Not assessed. A missing finding for these checks means "not checked", not "safe".

## Suggested direction
Re-run the scan. If a firewall or rate limit answered, allow the scanner through and re-run.

## Rules for this fix
1. Reproduce first. Confirm the issue actually exists before changing anything (run the reproduce command above when there is one). If it does not reproduce, say so and stop — do not "fix" a finding you cannot confirm.
2. Make the smallest change that resolves it. Do not refactor unrelated code.
3. Never weaken or remove an existing security check to make this finding go away.
4. If the real fix belongs in hosting or platform configuration rather than code, say exactly what to change and where, instead of forcing a code change.
5. When you are done, explain what you changed and why in one short paragraph a non-developer can understand.

INFO · Your site is telling attackers more about itself than it needs to.

Knowing exactly what software you run lets attackers pick attacks that are known to work on it. Revealing less costs nothing.

Evidence and fix prompt · FINGERPRINT

Framework fingerprint: Next.js (hosted on Vercel)

server: Vercel
_next/static or __NEXT_DATA__ in HTML

A security scan of this app found the issue below. Investigate and fix it.

## Finding
- Title: Framework fingerprint: Next.js (hosted on Vercel)
- Severity: info
- Rule: FINGERPRINT
- Area: fingerprint
- Observed at path: /

## What the scanner recorded
```
server: Vercel
_next/static or __NEXT_DATA__ in HTML
```

## What the scanner saw
Response headers and HTML indicate the site is built with Next.js and served by Vercel.

## Why it matters
Not a vulnerability — informational. Some frameworks have specific hardening guides.

## Rules for this fix
1. Reproduce first. Confirm the issue actually exists before changing anything (run the reproduce command above when there is one). If it does not reproduce, say so and stop — do not "fix" a finding you cannot confirm.
2. Make the smallest change that resolves it. Do not refactor unrelated code.
3. Never weaken or remove an existing security check to make this finding go away.
4. If the real fix belongs in hosting or platform configuration rather than code, say exactly what to change and where, instead of forcing a code change.
5. When you are done, explain what you changed and why in one short paragraph a non-developer can understand.

Release check · 11/2/2026, 4:22:44 AM UTC

gtsbahamas/shipsafe-web · https://seatrial.io · revision 8062fb4d

Website, exposure and versions: ran — 10 findings and notes
Open redirects: ran — Existing URL scanner; GET only, outside redirects never followed. Individual coverage notes apply.
Safe confirmation and combined risks: ran — 2 proof attempts, 0 combined risks
Agent wiring and prompt injection review: ran — 0 static findings. Live agent conversations are not run: they require POST/sign-in, beyond this read-only target.
OWASP benchmark: ran — OWASP Juice Shop 20.3.0: found 0 of 116 documented issues (0%), missed 116; 0 of 7 that Seatrial has a check for; confirmed extras 6 of 8; false alarms 0 of 9 scored findings. Isolated owned Juice Shop container; not a score for our live site.

Coverage and proof

Public GET/HEAD only. No sign-in, submitted forms, active agent conversations, customer sites or customer repositories.
Mail/domain registry checks are not run: they contact outside services. Database hosts, OPTIONS and Convex POST queries are refused.
Exposure/version assessment uses the scanner’s bundled advisory baseline when current feed storage cannot be read.
Refused by self-target scope: GET https://seatrial.io (action route)

0 combined risks; 2 proof steps recorded.

{
  "chains": [],
  "proof": [
    {
      "ruleId": "EXPOSURE-VERSION-UNKNOWN",
      "host": "seatrial.io",
      "path": "/",
      "at": "2026-11-02T04:22:51.689Z",
      "outcome": "not-run",
      "detail": "finding carries no version string to confirm"
    },
    {
      "ruleId": "EXPOSURE-VERSION-OK",
      "host": "seatrial.io",
      "path": "/",
      "at": "2026-11-02T04:22:51.689Z",
      "outcome": "not-run",
      "detail": "finding carries no version string to confirm"
    }
  ]
}

10 findings and coverage notes.

MEDIUM · Your pages have no backstop if a malicious script sneaks in.

This protection does not stop the break-in itself; it limits the damage when one happens. Right now that safety net is missing.

Evidence and fix prompt · HEADER-CSP-UNSAFE-INLINE-STYLE

CSP allows 'unsafe-inline' styles

content-security-policy: default-src 'self'; script-src 'self' 'nonce-MThhMzc5MDMtN2I4MS00NTdlLWI2MmItZTNmOTViZjJhYTVl' 'strict-dynamic'; style-src 'self' 'unsafe-inline' https://fonts.googleapis.com…

A security scan of this app found the issue below. Investigate and fix it.

## Finding
- Title: CSP allows 'unsafe-inline' styles
- Severity: medium
- Rule: HEADER-CSP-UNSAFE-INLINE-STYLE
- Area: headers
- Observed at path: /
- Header involved: Content-Security-Policy

## What the scanner recorded
```
content-security-policy: default-src 'self'; script-src 'self' 'nonce-MThhMzc5MDMtN2I4MS00NTdlLWI2MmItZTNmOTViZjJhYTVl' 'strict-dynamic'; style-src 'self' 'unsafe-inline' https://fonts.googleapis.com…
```

## What the scanner saw
Your Content-Security-Policy includes 'unsafe-inline' in style-src. Injected CSS runs — this does not execute scripts, but it is not harmless either.

LOW · Cross-Origin-Embedder-Policy is missing or too open

Evidence and fix prompt · HEADER-COEP-MISSING

Cross-Origin-Embedder-Policy is missing or too open

A security scan of this app found the issue below. Investigate and fix it.

## Finding
- Title: Cross-Origin-Embedder-Policy is missing or too open
- Severity: low
- Rule: HEADER-COEP-MISSING
- Area: headers
- Observed at path: /
- Header involved: Cross-Origin-Embedder-Policy

## What the scanner saw
No Cross-Origin-Embedder-Policy header was returned.

## Why it matters
Without COEP, the browser cannot enable crossOriginIsolated features (SharedArrayBuffer, precise performance.now()). It also leaves embedded cross-origin resources without the extra credentials-stripping the spec provides.

## Suggested direction
Add `Cross-Origin-Embedder-Policy: require-corp`. Third-party images/scripts you embed will need their own CORP or CORS opt-in; `credentialless` is an easier migration path.

## Rules for this fix
1. Reproduce first. Confirm the issue actually exists before changing anything (run the reproduce command above when there is one). If it does not reproduce, say so and stop — do not "fix" a finding you cannot confirm.
2. Make the smallest change that resolves it. Do not refactor unrelated code.
3. Never weaken or remove an existing security check to make this finding go away.
4. If the real fix belongs in hosting or platform configuration rather than code, say exactly what to change and where, instead of forcing a code change.
5. When you are done, explain what you changed and why in one short paragraph a non-developer can understand.

INFO · No reporting endpoints configured

You will never see CSP violations, deprecation reports, or intervention reports in production. Debugging CSP is much harder without this.

Evidence and fix prompt · HEADER-REPORT-TO-MISSING

No reporting endpoints configured

A security scan of this app found the issue below. Investigate and fix it.

## Finding
- Title: No reporting endpoints configured
- Severity: info
- Rule: HEADER-REPORT-TO-MISSING
- Area: reporting
- Observed at path: /
- Header involved: Reporting-Endpoints

## What the scanner saw
Neither `Report-To` nor `Reporting-Endpoints` header is set. CSP `report-uri` and `report-to` directives will silently drop reports.

## Why it matters
You will never see CSP violations, deprecation reports, or intervention reports in production. Debugging CSP is much harder without this.

## Suggested direction
Add `Reporting-Endpoints: default="https://your-endpoint/report"` and wire your CSP `report-to default` to it. Services like report-uri.com or Sentry handle the receiving side.

## Rules for this fix
1. Reproduce first. Confirm the issue actually exists before changing anything (run the reproduce command above when there is one). If it does not reproduce, say so and stop — do not "fix" a finding you cannot confirm.
2. Make the smallest change that resolves it. Do not refactor unrelated code.
3. Never weaken or remove an existing security check to make this finding go away.
4. If the real fix belongs in hosting or platform configuration rather than code, say exactly what to change and where, instead of forcing a code change.
5. When you are done, explain what you changed and why in one short paragraph a non-developer can understand.

INFO · We could not see which server software version you run. That is not the same as safe.

Hidden versions can still be old ones. Checking the version on the server, or letting us read what your code declares, tells you for sure.

Evidence and fix prompt · EXPOSURE-VERSION-UNKNOWN

UNKNOWN: Server software (Server and X-Powered-By headers)

No software version in the Server or X-Powered-By headers.

A security scan of this app found the issue below. Investigate and fix it.

## What the scanner recorded
```
No software version in the Server or X-Powered-By headers.
```

## What the scanner saw
The site does not say which server software or version it runs, so its headers cannot show whether it is exposed.

## Why it matters
Nobody can tell from here whether this is exposed. UNKNOWN is not safe; it means the check could not see.

INFO · Your website’s framework version has no known serious holes today.

We re-check automatically when new security advisories come out.

Evidence and fix prompt · EXPOSURE-VERSION-OK

OK: Next.js 16.4.3 (Next.js runtime in /_next/static/immutable/chunks/08mq80k63s_7m.js)

/_next/static/immutable/chunks/08mq80k63s_7m.js: …r.exports}u.ab="/ROOT/node_modules/.pnpm/next@16.4.3_@babel+core@7.29.0_@types+node@20.19.39_…

A security scan of this app found the issue below. Investigate and fix it.

## Finding
- Title: OK: Next.js 16.4.3 (Next.js runtime in /_next/static/immutable/chunks/08mq80k63s_7m.js)
- Severity: info
- Rule: EXPOSURE-VERSION-OK
- Area: software-versions
- Observed at path: /

## What the scanner recorded
```
/_next/static/immutable/chunks/08mq80k63s_7m.js: …r.exports}u.ab="/ROOT/node_modules/.pnpm/next@16.4.3_@babel+core@7.29.0_@types+node@20.19.39_…
```

## What the scanner saw
Next.js 16.4.3 (Next.js runtime in /_next/static/immutable/chunks/08mq80k63s_7m.js) is on a supported branch with no known vulnerable range covering it.

## Why it matters
No known exposure for this version today.

## Suggested direction
Nothing to do now. ShipSafe re-checks when new advisories land.

## Rules for this fix
1. Reproduce first. Confirm the issue actually exists before changing anything (run the reproduce command above when there is one). If it does not reproduce, say so and stop — do not "fix" a finding you cannot confirm.
2. Make the smallest change that resolves it. Do not refactor unrelated code.
3. Never weaken or remove an existing security check to make this finding go away.
4. If the real fix belongs in hosting or platform configuration rather than code, say exactly what to change and where, instead of forcing a code change.
5. When you are done, explain what you changed and why in one short paragraph a non-developer can understand.

INFO · Traffic between your users and your app may not always be encrypted.

On open Wi-Fi, unencrypted traffic can be read or altered by whoever runs the network. Browsers also warn users away from sites that get this wrong.

Evidence and fix prompt · TLS-ISSUER

TLS issuer: Let's Encrypt

issuer: Let's Encrypt
notAfter: Jan 19 22:40:26 2027 GMT

A security scan of this app found the issue below. Investigate and fix it.

## Finding
- Title: TLS issuer: Let's Encrypt
- Severity: info
- Rule: TLS-ISSUER
- Area: tls

## What the scanner recorded
```
issuer: Let's Encrypt
notAfter: Jan 19 22:40:26 2027 GMT
```

## What the scanner saw
Certificate issued by Let's Encrypt.

## Why it matters
Informational only.

## Rules for this fix
1. Reproduce first. Confirm the issue actually exists before changing anything (run the reproduce command above when there is one). If it does not reproduce, say so and stop — do not "fix" a finding you cannot confirm.
2. Make the smallest change that resolves it. Do not refactor unrelated code.
3. Never weaken or remove an existing security check to make this finding go away.
4. If the real fix belongs in hosting or platform configuration rather than code, say exactly what to change and where, instead of forcing a code change.
5. When you are done, explain what you changed and why in one short paragraph a non-developer can understand.

INFO · Traffic between your users and your app may not always be encrypted.

On open Wi-Fi, unencrypted traffic can be read or altered by whoever runs the network. Browsers also warn users away from sites that get this wrong.

Evidence and fix prompt · TLS-CHAIN-DEPTH

TLS certificate chain length: 3

chain length: 3

A security scan of this app found the issue below. Investigate and fix it.

## Finding
- Title: TLS certificate chain length: 3
- Severity: info
- Rule: TLS-CHAIN-DEPTH
- Area: tls

## What the scanner recorded
```
chain length: 3
```

## What the scanner saw
The certificate chain presented by the server is 3 certificate(s) long before the root store takes over.

## Why it matters
Informational only. A typical web cert is depth 2 (leaf + intermediate). Deeper chains add latency on new connections because each intermediate adds bytes to the handshake.

## Rules for this fix
1. Reproduce first. Confirm the issue actually exists before changing anything (run the reproduce command above when there is one). If it does not reproduce, say so and stop — do not "fix" a finding you cannot confirm.
2. Make the smallest change that resolves it. Do not refactor unrelated code.
3. Never weaken or remove an existing security check to make this finding go away.
4. If the real fix belongs in hosting or platform configuration rather than code, say exactly what to change and where, instead of forcing a code change.
5. When you are done, explain what you changed and why in one short paragraph a non-developer can understand.

INFO · Traffic between your users and your app may not always be encrypted.

On open Wi-Fi, unencrypted traffic can be read or altered by whoever runs the network. Browsers also warn users away from sites that get this wrong.

Evidence and fix prompt · TLS-HSTS-PRELOAD-NOT-SUBMITTED

HSTS header is preload-ready but domain is not in the preload list

strict-transport-security: max-age=63072000; includeSubDomains; preload

A security scan of this app found the issue below. Investigate and fix it.

## What the scanner recorded
```
strict-transport-security: max-age=63072000; includeSubDomains; preload
```

## Why it matters
Minor — without preload submission, the first visit on a new network is still cleartext-eligible for users who haven't visited before.

## Suggested direction
Submit your domain at https://hstspreload.org. Note that preload is a one-way door: removal takes months.

INFO · We could not check this part, so it is not known to be safe.

The scan did not get the answer it needed. This is a gap in what we saw, not a pass. Running the scan again usually fills it.

Evidence and fix prompt · SCAN-PARTIALLY-BLOCKED-BY-FIREWALL

Scan coverage reduced — Vercel challenged part of it

JavaScript bundles: 2 of 10 answered by Vercel challenge page
Common-path probes: 8 of 28 answered by Vercel challenge page
body is the "Vercel Security Checkpoint" page

A security scan of this app found the issue below. Investigate and fix it.

## Finding
- Title: Scan coverage reduced — Vercel challenged part of it
- Severity: info
- Rule: SCAN-PARTIALLY-BLOCKED-BY-FIREWALL
- Area: coverage
- Observed at path: /

## What the scanner recorded
```
JavaScript bundles: 2 of 10 answered by Vercel challenge page
Common-path probes: 8 of 28 answered by Vercel challenge page
body is the "Vercel Security Checkpoint" page
```

## What the scanner saw
The front page answered normally, but Vercel challenge page intervened on later requests. JavaScript bundles: 2 of 10 answered by Vercel challenge page. Common-path probes: 8 of 28 answered by Vercel challenge page. Endpoint discovery from JavaScript found nothing because it never saw the JavaScript. Endpoint rows marked forbidden (403) with a firewall note were answered by the firewall, not the application; they are not evidence those paths exist.

## Why it matters
The endpoint inventory and the exposure checks are incomplete. A missing finding here means "not assessed", not "not present".

INFO · Your site is telling attackers more about itself than it needs to.

Knowing exactly what software you run lets attackers pick attacks that are known to work on it. Revealing less costs nothing.

Evidence and fix prompt · FINGERPRINT

Framework fingerprint: Next.js (hosted on Vercel)

server: Vercel
_next/static or __NEXT_DATA__ in HTML

A security scan of this app found the issue below. Investigate and fix it.

## Finding
- Title: Framework fingerprint: Next.js (hosted on Vercel)
- Severity: info
- Rule: FINGERPRINT
- Area: fingerprint
- Observed at path: /

## What the scanner recorded
```
server: Vercel
_next/static or __NEXT_DATA__ in HTML
```

## What the scanner saw
Response headers and HTML indicate the site is built with Next.js and served by Vercel.

## Why it matters
Not a vulnerability — informational. Some frameworks have specific hardening guides.

## Rules for this fix
1. Reproduce first. Confirm the issue actually exists before changing anything (run the reproduce command above when there is one). If it does not reproduce, say so and stop — do not "fix" a finding you cannot confirm.
2. Make the smallest change that resolves it. Do not refactor unrelated code.
3. Never weaken or remove an existing security check to make this finding go away.
4. If the real fix belongs in hosting or platform configuration rather than code, say exactly what to change and where, instead of forcing a code change.
5. When you are done, explain what you changed and why in one short paragraph a non-developer can understand.

Release check · 11/2/2026, 4:01:56 AM UTC

gtsbahamas/shipsafe-web · https://seatrial.io · revision 9f6862e6

Website, exposure and versions: ran — 10 findings and notes
Open redirects: ran — Existing URL scanner; GET only, outside redirects never followed. Individual coverage notes apply.
Safe confirmation and combined risks: ran — 2 proof attempts, 0 combined risks
Agent wiring and prompt injection review: ran — 0 static findings. Live agent conversations are not run: they require POST/sign-in, beyond this read-only target.
OWASP benchmark: ran — OWASP Juice Shop 20.3.0: found 0 of 116 documented issues (0%), missed 116; 0 of 7 that Seatrial has a check for; confirmed extras 6 of 8; false alarms 0 of 9 scored findings. Isolated owned Juice Shop container; not a score for our live site.

Coverage and proof

Public GET/HEAD only. No sign-in, submitted forms, active agent conversations, customer sites or customer repositories.
Mail/domain registry checks are not run: they contact outside services. Database hosts, OPTIONS and Convex POST queries are refused.
Exposure/version assessment uses the scanner’s bundled advisory baseline when current feed storage cannot be read.
Refused by self-target scope: GET https://seatrial.io (action route)

0 combined risks; 2 proof steps recorded.

{
  "chains": [],
  "proof": [
    {
      "ruleId": "EXPOSURE-VERSION-UNKNOWN",
      "host": "seatrial.io",
      "path": "/",
      "at": "2026-11-02T04:02:03.015Z",
      "outcome": "not-run",
      "detail": "finding carries no version string to confirm"
    },
    {
      "ruleId": "EXPOSURE-VERSION-UNKNOWN",
      "host": "seatrial.io",
      "path": "/",
      "at": "2026-11-02T04:02:03.015Z",
      "outcome": "not-run",
      "detail": "finding carries no version string to confirm"
    }
  ]
}

10 findings and coverage notes.

MEDIUM · Your pages have no backstop if a malicious script sneaks in.

This protection does not stop the break-in itself; it limits the damage when one happens. Right now that safety net is missing.

Evidence and fix prompt · HEADER-CSP-UNSAFE-INLINE-STYLE

CSP allows 'unsafe-inline' styles

content-security-policy: default-src 'self'; script-src 'self' 'nonce-NTkxM2Y0NzAtNjM3OC00OGNjLThkM2MtMDdmMDliMDU5NmRm' 'strict-dynamic'; style-src 'self' 'unsafe-inline' https://fonts.googleapis.com…

A security scan of this app found the issue below. Investigate and fix it.

## Finding
- Title: CSP allows 'unsafe-inline' styles
- Severity: medium
- Rule: HEADER-CSP-UNSAFE-INLINE-STYLE
- Area: headers
- Observed at path: /
- Header involved: Content-Security-Policy

## What the scanner recorded
```
content-security-policy: default-src 'self'; script-src 'self' 'nonce-NTkxM2Y0NzAtNjM3OC00OGNjLThkM2MtMDdmMDliMDU5NmRm' 'strict-dynamic'; style-src 'self' 'unsafe-inline' https://fonts.googleapis.com…
```

## What the scanner saw
Your Content-Security-Policy includes 'unsafe-inline' in style-src. Injected CSS runs — this does not execute scripts, but it is not harmless either.

LOW · Cross-Origin-Embedder-Policy is missing or too open

Evidence and fix prompt · HEADER-COEP-MISSING

Cross-Origin-Embedder-Policy is missing or too open

A security scan of this app found the issue below. Investigate and fix it.

## Finding
- Title: Cross-Origin-Embedder-Policy is missing or too open
- Severity: low
- Rule: HEADER-COEP-MISSING
- Area: headers
- Observed at path: /
- Header involved: Cross-Origin-Embedder-Policy

## What the scanner saw
No Cross-Origin-Embedder-Policy header was returned.

## Why it matters
Without COEP, the browser cannot enable crossOriginIsolated features (SharedArrayBuffer, precise performance.now()). It also leaves embedded cross-origin resources without the extra credentials-stripping the spec provides.

## Suggested direction
Add `Cross-Origin-Embedder-Policy: require-corp`. Third-party images/scripts you embed will need their own CORP or CORS opt-in; `credentialless` is an easier migration path.

## Rules for this fix
1. Reproduce first. Confirm the issue actually exists before changing anything (run the reproduce command above when there is one). If it does not reproduce, say so and stop — do not "fix" a finding you cannot confirm.
2. Make the smallest change that resolves it. Do not refactor unrelated code.
3. Never weaken or remove an existing security check to make this finding go away.
4. If the real fix belongs in hosting or platform configuration rather than code, say exactly what to change and where, instead of forcing a code change.
5. When you are done, explain what you changed and why in one short paragraph a non-developer can understand.

INFO · No reporting endpoints configured

You will never see CSP violations, deprecation reports, or intervention reports in production. Debugging CSP is much harder without this.

Evidence and fix prompt · HEADER-REPORT-TO-MISSING

No reporting endpoints configured

A security scan of this app found the issue below. Investigate and fix it.

## Finding
- Title: No reporting endpoints configured
- Severity: info
- Rule: HEADER-REPORT-TO-MISSING
- Area: reporting
- Observed at path: /
- Header involved: Reporting-Endpoints

## What the scanner saw
Neither `Report-To` nor `Reporting-Endpoints` header is set. CSP `report-uri` and `report-to` directives will silently drop reports.

## Why it matters
You will never see CSP violations, deprecation reports, or intervention reports in production. Debugging CSP is much harder without this.

## Suggested direction
Add `Reporting-Endpoints: default="https://your-endpoint/report"` and wire your CSP `report-to default` to it. Services like report-uri.com or Sentry handle the receiving side.

## Rules for this fix
1. Reproduce first. Confirm the issue actually exists before changing anything (run the reproduce command above when there is one). If it does not reproduce, say so and stop — do not "fix" a finding you cannot confirm.
2. Make the smallest change that resolves it. Do not refactor unrelated code.
3. Never weaken or remove an existing security check to make this finding go away.
4. If the real fix belongs in hosting or platform configuration rather than code, say exactly what to change and where, instead of forcing a code change.
5. When you are done, explain what you changed and why in one short paragraph a non-developer can understand.

INFO · We could not see which server software version you run. That is not the same as safe.

Hidden versions can still be old ones. Checking the version on the server, or letting us read what your code declares, tells you for sure.

Evidence and fix prompt · EXPOSURE-VERSION-UNKNOWN

UNKNOWN: Server software (Server and X-Powered-By headers)

No software version in the Server or X-Powered-By headers.

A security scan of this app found the issue below. Investigate and fix it.

## What the scanner recorded
```
No software version in the Server or X-Powered-By headers.
```

## What the scanner saw
The site does not say which server software or version it runs, so its headers cannot show whether it is exposed.

## Why it matters
Nobody can tell from here whether this is exposed. UNKNOWN is not safe; it means the check could not see.

INFO · We could not see which version of your website’s framework you run. That is not the same as safe.

Hidden versions can still be old ones. Your project’s lockfile states the exact version, or connect the code so we can read it.

Evidence and fix prompt · EXPOSURE-VERSION-UNKNOWN

UNKNOWN: Next.js (page and JavaScript bundles)

Next.js markers (/_next/ assets in the HTML); no version string in the page or the 1 bundle(s) read.

A security scan of this app found the issue below. Investigate and fix it.

## Finding
- Title: UNKNOWN: Next.js (page and JavaScript bundles)
- Severity: info
- Rule: EXPOSURE-VERSION-UNKNOWN
- Area: software-versions
- Observed at path: /

## What the scanner recorded
```
Next.js markers (/_next/ assets in the HTML); no version string in the page or the 1 bundle(s) read.
```

## What the scanner saw
Next.js answers in the page and JavaScript bundles, but its version is hidden.

## Why it matters
Nobody can tell from here whether this is exposed. UNKNOWN is not safe; it means the check could not see.

## Suggested direction
UNKNOWN is not the same as safe: it means the version could not be seen. To find out, read the exact `next` version in the project's lockfile (or run `npm ls next`), or connect the repo so ShipSafe can read what it declares.

INFO · Traffic between your users and your app may not always be encrypted.

On open Wi-Fi, unencrypted traffic can be read or altered by whoever runs the network. Browsers also warn users away from sites that get this wrong.

Evidence and fix prompt · TLS-ISSUER

TLS issuer: Let's Encrypt

issuer: Let's Encrypt
notAfter: Jan 19 22:40:26 2027 GMT

A security scan of this app found the issue below. Investigate and fix it.

## Finding
- Title: TLS issuer: Let's Encrypt
- Severity: info
- Rule: TLS-ISSUER
- Area: tls

## What the scanner recorded
```
issuer: Let's Encrypt
notAfter: Jan 19 22:40:26 2027 GMT
```

## What the scanner saw
Certificate issued by Let's Encrypt.

## Why it matters
Informational only.

## Rules for this fix
1. Reproduce first. Confirm the issue actually exists before changing anything (run the reproduce command above when there is one). If it does not reproduce, say so and stop — do not "fix" a finding you cannot confirm.
2. Make the smallest change that resolves it. Do not refactor unrelated code.
3. Never weaken or remove an existing security check to make this finding go away.
4. If the real fix belongs in hosting or platform configuration rather than code, say exactly what to change and where, instead of forcing a code change.
5. When you are done, explain what you changed and why in one short paragraph a non-developer can understand.

INFO · Traffic between your users and your app may not always be encrypted.

On open Wi-Fi, unencrypted traffic can be read or altered by whoever runs the network. Browsers also warn users away from sites that get this wrong.

Evidence and fix prompt · TLS-CHAIN-DEPTH

TLS certificate chain length: 3

chain length: 3

A security scan of this app found the issue below. Investigate and fix it.

## Finding
- Title: TLS certificate chain length: 3
- Severity: info
- Rule: TLS-CHAIN-DEPTH
- Area: tls

## What the scanner recorded
```
chain length: 3
```

## What the scanner saw
The certificate chain presented by the server is 3 certificate(s) long before the root store takes over.

## Why it matters
Informational only. A typical web cert is depth 2 (leaf + intermediate). Deeper chains add latency on new connections because each intermediate adds bytes to the handshake.

## Rules for this fix
1. Reproduce first. Confirm the issue actually exists before changing anything (run the reproduce command above when there is one). If it does not reproduce, say so and stop — do not "fix" a finding you cannot confirm.
2. Make the smallest change that resolves it. Do not refactor unrelated code.
3. Never weaken or remove an existing security check to make this finding go away.
4. If the real fix belongs in hosting or platform configuration rather than code, say exactly what to change and where, instead of forcing a code change.
5. When you are done, explain what you changed and why in one short paragraph a non-developer can understand.

INFO · Traffic between your users and your app may not always be encrypted.

On open Wi-Fi, unencrypted traffic can be read or altered by whoever runs the network. Browsers also warn users away from sites that get this wrong.

Evidence and fix prompt · TLS-HSTS-PRELOAD-NOT-SUBMITTED

HSTS header is preload-ready but domain is not in the preload list

strict-transport-security: max-age=63072000; includeSubDomains; preload

A security scan of this app found the issue below. Investigate and fix it.

## What the scanner recorded
```
strict-transport-security: max-age=63072000; includeSubDomains; preload
```

## Why it matters
Minor — without preload submission, the first visit on a new network is still cleartext-eligible for users who haven't visited before.

## Suggested direction
Submit your domain at https://hstspreload.org. Note that preload is a one-way door: removal takes months.

INFO · We could not check this part, so it is not known to be safe.

The scan did not get the answer it needed. This is a gap in what we saw, not a pass. Running the scan again usually fills it.

Evidence and fix prompt · SCAN-PARTIALLY-BLOCKED-BY-FIREWALL

Scan coverage reduced — Vercel challenged part of it

JavaScript bundles: 9 of 10 answered by Vercel challenge page
Common-path probes: 18 of 30 answered by Vercel challenge page
body is the "Vercel Security Checkpoint" page

A security scan of this app found the issue below. Investigate and fix it.

## Finding
- Title: Scan coverage reduced — Vercel challenged part of it
- Severity: info
- Rule: SCAN-PARTIALLY-BLOCKED-BY-FIREWALL
- Area: coverage
- Observed at path: /

## What the scanner recorded
```
JavaScript bundles: 9 of 10 answered by Vercel challenge page
Common-path probes: 18 of 30 answered by Vercel challenge page
body is the "Vercel Security Checkpoint" page
```

## What the scanner saw
The front page answered normally, but Vercel challenge page intervened on later requests. JavaScript bundles: 9 of 10 answered by Vercel challenge page. Common-path probes: 18 of 30 answered by Vercel challenge page. Endpoint discovery from JavaScript found nothing because it never saw the JavaScript. Endpoint rows marked forbidden (403) with a firewall note were answered by the firewall, not the application; they are not evidence those paths exist.

## Why it matters
The endpoint inventory and the exposure checks are incomplete. A missing finding here means "not assessed", not "not present".

INFO · Your site is telling attackers more about itself than it needs to.

Knowing exactly what software you run lets attackers pick attacks that are known to work on it. Revealing less costs nothing.

Evidence and fix prompt · FINGERPRINT

Framework fingerprint: Next.js (hosted on Vercel)

server: Vercel
_next/static or __NEXT_DATA__ in HTML

A security scan of this app found the issue below. Investigate and fix it.

## Finding
- Title: Framework fingerprint: Next.js (hosted on Vercel)
- Severity: info
- Rule: FINGERPRINT
- Area: fingerprint
- Observed at path: /

## What the scanner recorded
```
server: Vercel
_next/static or __NEXT_DATA__ in HTML
```

## What the scanner saw
Response headers and HTML indicate the site is built with Next.js and served by Vercel.

## Why it matters
Not a vulnerability — informational. Some frameworks have specific hardening guides.

## Rules for this fix
1. Reproduce first. Confirm the issue actually exists before changing anything (run the reproduce command above when there is one). If it does not reproduce, say so and stop — do not "fix" a finding you cannot confirm.
2. Make the smallest change that resolves it. Do not refactor unrelated code.
3. Never weaken or remove an existing security check to make this finding go away.
4. If the real fix belongs in hosting or platform configuration rather than code, say exactly what to change and where, instead of forcing a code change.
5. When you are done, explain what you changed and why in one short paragraph a non-developer can understand.

Release check · 11/2/2026, 4:00:00 AM UTC

gtsbahamas/shipsafe-web · https://seatrial.io · revision 04d92b15

Website, exposure and versions: ran — 10 findings and notes
Open redirects: ran — Existing URL scanner; GET only, outside redirects never followed. Individual coverage notes apply.
Safe confirmation and combined risks: ran — 2 proof attempts, 0 combined risks
Agent wiring and prompt injection review: ran — 0 static findings. Live agent conversations are not run: they require POST/sign-in, beyond this read-only target.
OWASP benchmark: ran — OWASP Juice Shop 20.3.0: found 0 of 116 documented issues (0%), missed 116; 0 of 7 that Seatrial has a check for; confirmed extras 6 of 8; false alarms 0 of 9 scored findings. Isolated owned Juice Shop container; not a score for our live site.

Coverage and proof

Public GET/HEAD only. No sign-in, submitted forms, active agent conversations, customer sites or customer repositories.
Mail/domain registry checks are not run: they contact outside services. Database hosts, OPTIONS and Convex POST queries are refused.
Exposure/version assessment uses the scanner’s bundled advisory baseline when current feed storage cannot be read.
Refused by self-target scope: GET https://seatrial.io (action route)

0 combined risks; 2 proof steps recorded.

{
  "chains": [],
  "proof": [
    {
      "ruleId": "EXPOSURE-VERSION-UNKNOWN",
      "host": "seatrial.io",
      "path": "/",
      "at": "2026-11-02T04:00:07.914Z",
      "outcome": "not-run",
      "detail": "finding carries no version string to confirm"
    },
    {
      "ruleId": "EXPOSURE-VERSION-OK",
      "host": "seatrial.io",
      "path": "/",
      "at": "2026-11-02T04:00:07.914Z",
      "outcome": "not-run",
      "detail": "finding carries no version string to confirm"
    }
  ]
}

10 findings and coverage notes.

MEDIUM · Your pages have no backstop if a malicious script sneaks in.

This protection does not stop the break-in itself; it limits the damage when one happens. Right now that safety net is missing.

Evidence and fix prompt · HEADER-CSP-UNSAFE-INLINE-STYLE

CSP allows 'unsafe-inline' styles

content-security-policy: default-src 'self'; script-src 'self' 'nonce-MGZhOGVlZDUtNTIyYy00ZDliLWE3MmItNzJmYzJlOWY2NGVj' 'strict-dynamic'; style-src 'self' 'unsafe-inline' https://fonts.googleapis.com…

A security scan of this app found the issue below. Investigate and fix it.

## Finding
- Title: CSP allows 'unsafe-inline' styles
- Severity: medium
- Rule: HEADER-CSP-UNSAFE-INLINE-STYLE
- Area: headers
- Observed at path: /
- Header involved: Content-Security-Policy

## What the scanner recorded
```
content-security-policy: default-src 'self'; script-src 'self' 'nonce-MGZhOGVlZDUtNTIyYy00ZDliLWE3MmItNzJmYzJlOWY2NGVj' 'strict-dynamic'; style-src 'self' 'unsafe-inline' https://fonts.googleapis.com…
```

## What the scanner saw
Your Content-Security-Policy includes 'unsafe-inline' in style-src. Injected CSS runs — this does not execute scripts, but it is not harmless either.

LOW · Cross-Origin-Embedder-Policy is missing or too open

Evidence and fix prompt · HEADER-COEP-MISSING

Cross-Origin-Embedder-Policy is missing or too open

A security scan of this app found the issue below. Investigate and fix it.

## Finding
- Title: Cross-Origin-Embedder-Policy is missing or too open
- Severity: low
- Rule: HEADER-COEP-MISSING
- Area: headers
- Observed at path: /
- Header involved: Cross-Origin-Embedder-Policy

## What the scanner saw
No Cross-Origin-Embedder-Policy header was returned.

## Why it matters
Without COEP, the browser cannot enable crossOriginIsolated features (SharedArrayBuffer, precise performance.now()). It also leaves embedded cross-origin resources without the extra credentials-stripping the spec provides.

## Suggested direction
Add `Cross-Origin-Embedder-Policy: require-corp`. Third-party images/scripts you embed will need their own CORP or CORS opt-in; `credentialless` is an easier migration path.

## Rules for this fix
1. Reproduce first. Confirm the issue actually exists before changing anything (run the reproduce command above when there is one). If it does not reproduce, say so and stop — do not "fix" a finding you cannot confirm.
2. Make the smallest change that resolves it. Do not refactor unrelated code.
3. Never weaken or remove an existing security check to make this finding go away.
4. If the real fix belongs in hosting or platform configuration rather than code, say exactly what to change and where, instead of forcing a code change.
5. When you are done, explain what you changed and why in one short paragraph a non-developer can understand.

INFO · No reporting endpoints configured

You will never see CSP violations, deprecation reports, or intervention reports in production. Debugging CSP is much harder without this.

Evidence and fix prompt · HEADER-REPORT-TO-MISSING

No reporting endpoints configured

A security scan of this app found the issue below. Investigate and fix it.

## Finding
- Title: No reporting endpoints configured
- Severity: info
- Rule: HEADER-REPORT-TO-MISSING
- Area: reporting
- Observed at path: /
- Header involved: Reporting-Endpoints

## What the scanner saw
Neither `Report-To` nor `Reporting-Endpoints` header is set. CSP `report-uri` and `report-to` directives will silently drop reports.

## Why it matters
You will never see CSP violations, deprecation reports, or intervention reports in production. Debugging CSP is much harder without this.

## Suggested direction
Add `Reporting-Endpoints: default="https://your-endpoint/report"` and wire your CSP `report-to default` to it. Services like report-uri.com or Sentry handle the receiving side.

## Rules for this fix
1. Reproduce first. Confirm the issue actually exists before changing anything (run the reproduce command above when there is one). If it does not reproduce, say so and stop — do not "fix" a finding you cannot confirm.
2. Make the smallest change that resolves it. Do not refactor unrelated code.
3. Never weaken or remove an existing security check to make this finding go away.
4. If the real fix belongs in hosting or platform configuration rather than code, say exactly what to change and where, instead of forcing a code change.
5. When you are done, explain what you changed and why in one short paragraph a non-developer can understand.

INFO · We could not see which server software version you run. That is not the same as safe.

Hidden versions can still be old ones. Checking the version on the server, or letting us read what your code declares, tells you for sure.

Evidence and fix prompt · EXPOSURE-VERSION-UNKNOWN

UNKNOWN: Server software (Server and X-Powered-By headers)

No software version in the Server or X-Powered-By headers.

A security scan of this app found the issue below. Investigate and fix it.

## What the scanner recorded
```
No software version in the Server or X-Powered-By headers.
```

## What the scanner saw
The site does not say which server software or version it runs, so its headers cannot show whether it is exposed.

## Why it matters
Nobody can tell from here whether this is exposed. UNKNOWN is not safe; it means the check could not see.

INFO · Your website’s framework version has no known serious holes today.

We re-check automatically when new security advisories come out.

Evidence and fix prompt · EXPOSURE-VERSION-OK

OK: Next.js 16.4.3 (Next.js runtime in /_next/static/immutable/chunks/08mq80k63s_7m.js)

/_next/static/immutable/chunks/08mq80k63s_7m.js: …r.exports}u.ab="/ROOT/node_modules/.pnpm/next@16.4.3_@babel+core@7.29.0_@types+node@20.19.39_…

A security scan of this app found the issue below. Investigate and fix it.

## Finding
- Title: OK: Next.js 16.4.3 (Next.js runtime in /_next/static/immutable/chunks/08mq80k63s_7m.js)
- Severity: info
- Rule: EXPOSURE-VERSION-OK
- Area: software-versions
- Observed at path: /

## What the scanner recorded
```
/_next/static/immutable/chunks/08mq80k63s_7m.js: …r.exports}u.ab="/ROOT/node_modules/.pnpm/next@16.4.3_@babel+core@7.29.0_@types+node@20.19.39_…
```

## What the scanner saw
Next.js 16.4.3 (Next.js runtime in /_next/static/immutable/chunks/08mq80k63s_7m.js) is on a supported branch with no known vulnerable range covering it.

## Why it matters
No known exposure for this version today.

## Suggested direction
Nothing to do now. ShipSafe re-checks when new advisories land.

## Rules for this fix
1. Reproduce first. Confirm the issue actually exists before changing anything (run the reproduce command above when there is one). If it does not reproduce, say so and stop — do not "fix" a finding you cannot confirm.
2. Make the smallest change that resolves it. Do not refactor unrelated code.
3. Never weaken or remove an existing security check to make this finding go away.
4. If the real fix belongs in hosting or platform configuration rather than code, say exactly what to change and where, instead of forcing a code change.
5. When you are done, explain what you changed and why in one short paragraph a non-developer can understand.

INFO · Traffic between your users and your app may not always be encrypted.

On open Wi-Fi, unencrypted traffic can be read or altered by whoever runs the network. Browsers also warn users away from sites that get this wrong.

Evidence and fix prompt · TLS-ISSUER

TLS issuer: Let's Encrypt

issuer: Let's Encrypt
notAfter: Jan 19 22:40:26 2027 GMT

A security scan of this app found the issue below. Investigate and fix it.

## Finding
- Title: TLS issuer: Let's Encrypt
- Severity: info
- Rule: TLS-ISSUER
- Area: tls

## What the scanner recorded
```
issuer: Let's Encrypt
notAfter: Jan 19 22:40:26 2027 GMT
```

## What the scanner saw
Certificate issued by Let's Encrypt.

## Why it matters
Informational only.

## Rules for this fix
1. Reproduce first. Confirm the issue actually exists before changing anything (run the reproduce command above when there is one). If it does not reproduce, say so and stop — do not "fix" a finding you cannot confirm.
2. Make the smallest change that resolves it. Do not refactor unrelated code.
3. Never weaken or remove an existing security check to make this finding go away.
4. If the real fix belongs in hosting or platform configuration rather than code, say exactly what to change and where, instead of forcing a code change.
5. When you are done, explain what you changed and why in one short paragraph a non-developer can understand.

INFO · Traffic between your users and your app may not always be encrypted.

On open Wi-Fi, unencrypted traffic can be read or altered by whoever runs the network. Browsers also warn users away from sites that get this wrong.

Evidence and fix prompt · TLS-CHAIN-DEPTH

TLS certificate chain length: 3

chain length: 3

A security scan of this app found the issue below. Investigate and fix it.

## Finding
- Title: TLS certificate chain length: 3
- Severity: info
- Rule: TLS-CHAIN-DEPTH
- Area: tls

## What the scanner recorded
```
chain length: 3
```

## What the scanner saw
The certificate chain presented by the server is 3 certificate(s) long before the root store takes over.

## Why it matters
Informational only. A typical web cert is depth 2 (leaf + intermediate). Deeper chains add latency on new connections because each intermediate adds bytes to the handshake.

## Rules for this fix
1. Reproduce first. Confirm the issue actually exists before changing anything (run the reproduce command above when there is one). If it does not reproduce, say so and stop — do not "fix" a finding you cannot confirm.
2. Make the smallest change that resolves it. Do not refactor unrelated code.
3. Never weaken or remove an existing security check to make this finding go away.
4. If the real fix belongs in hosting or platform configuration rather than code, say exactly what to change and where, instead of forcing a code change.
5. When you are done, explain what you changed and why in one short paragraph a non-developer can understand.

INFO · Traffic between your users and your app may not always be encrypted.

On open Wi-Fi, unencrypted traffic can be read or altered by whoever runs the network. Browsers also warn users away from sites that get this wrong.

Evidence and fix prompt · TLS-HSTS-PRELOAD-NOT-SUBMITTED

HSTS header is preload-ready but domain is not in the preload list

strict-transport-security: max-age=63072000; includeSubDomains; preload

A security scan of this app found the issue below. Investigate and fix it.

## What the scanner recorded
```
strict-transport-security: max-age=63072000; includeSubDomains; preload
```

## Why it matters
Minor — without preload submission, the first visit on a new network is still cleartext-eligible for users who haven't visited before.

## Suggested direction
Submit your domain at https://hstspreload.org. Note that preload is a one-way door: removal takes months.

INFO · We could not check this part, so it is not known to be safe.

The scan did not get the answer it needed. This is a gap in what we saw, not a pass. Running the scan again usually fills it.

Evidence and fix prompt · SCAN-PARTIALLY-BLOCKED-BY-FIREWALL

Scan coverage reduced — Vercel challenged part of it

Common-path probes: 10 of 30 answered by Vercel challenge page
body is the "Vercel Security Checkpoint" page

A security scan of this app found the issue below. Investigate and fix it.

## Finding
- Title: Scan coverage reduced — Vercel challenged part of it
- Severity: info
- Rule: SCAN-PARTIALLY-BLOCKED-BY-FIREWALL
- Area: coverage
- Observed at path: /

## What the scanner recorded
```
Common-path probes: 10 of 30 answered by Vercel challenge page
body is the "Vercel Security Checkpoint" page
```

## What the scanner saw
The front page answered normally, but Vercel challenge page intervened on later requests. Common-path probes: 10 of 30 answered by Vercel challenge page. Endpoint rows marked forbidden (403) with a firewall note were answered by the firewall, not the application; they are not evidence those paths exist.

## Why it matters
The endpoint inventory and the exposure checks are incomplete. A missing finding here means "not assessed", not "not present".

INFO · Your site is telling attackers more about itself than it needs to.

Knowing exactly what software you run lets attackers pick attacks that are known to work on it. Revealing less costs nothing.

Evidence and fix prompt · FINGERPRINT

Framework fingerprint: Next.js (hosted on Vercel)

server: Vercel
_next/static or __NEXT_DATA__ in HTML

A security scan of this app found the issue below. Investigate and fix it.

## Finding
- Title: Framework fingerprint: Next.js (hosted on Vercel)
- Severity: info
- Rule: FINGERPRINT
- Area: fingerprint
- Observed at path: /

## What the scanner recorded
```
server: Vercel
_next/static or __NEXT_DATA__ in HTML
```

## What the scanner saw
Response headers and HTML indicate the site is built with Next.js and served by Vercel.

## Why it matters
Not a vulnerability — informational. Some frameworks have specific hardening guides.

## Rules for this fix
1. Reproduce first. Confirm the issue actually exists before changing anything (run the reproduce command above when there is one). If it does not reproduce, say so and stop — do not "fix" a finding you cannot confirm.
2. Make the smallest change that resolves it. Do not refactor unrelated code.
3. Never weaken or remove an existing security check to make this finding go away.
4. If the real fix belongs in hosting or platform configuration rather than code, say exactly what to change and where, instead of forcing a code change.
5. When you are done, explain what you changed and why in one short paragraph a non-developer can understand.

Release check · 11/2/2026, 3:05:47 AM UTC

gtsbahamas/shipsafe-web · https://seatrial.io · revision 5058f47e

Website, exposure and versions: ran — 10 findings and notes
Open redirects: ran — Existing URL scanner; GET only, outside redirects never followed. Individual coverage notes apply.
Safe confirmation and combined risks: ran — 2 proof attempts, 0 combined risks
Agent wiring and prompt injection review: ran — 0 static findings. Live agent conversations are not run: they require POST/sign-in, beyond this read-only target.
OWASP benchmark: ran — OWASP Juice Shop 20.3.0: found 0 of 116 documented issues (0%), missed 116; 0 of 7 that Seatrial has a check for; confirmed extras 6 of 8; false alarms 0 of 9 scored findings. Isolated owned Juice Shop container; not a score for our live site.

Coverage and proof

Public GET/HEAD only. No sign-in, submitted forms, active agent conversations, customer sites or customer repositories.
Mail/domain registry checks are not run: they contact outside services. Database hosts, OPTIONS and Convex POST queries are refused.
Exposure/version assessment uses the scanner’s bundled advisory baseline when current feed storage cannot be read.
Refused by self-target scope: GET https://seatrial.io (action route)

0 combined risks; 2 proof steps recorded.

{
  "chains": [],
  "proof": [
    {
      "ruleId": "EXPOSURE-VERSION-UNKNOWN",
      "host": "seatrial.io",
      "path": "/",
      "at": "2026-11-02T03:05:56.022Z",
      "outcome": "not-run",
      "detail": "finding carries no version string to confirm"
    },
    {
      "ruleId": "EXPOSURE-VERSION-OK",
      "host": "seatrial.io",
      "path": "/",
      "at": "2026-11-02T03:05:56.022Z",
      "outcome": "not-run",
      "detail": "finding carries no version string to confirm"
    }
  ]
}

10 findings and coverage notes.

MEDIUM · Your pages have no backstop if a malicious script sneaks in.

This protection does not stop the break-in itself; it limits the damage when one happens. Right now that safety net is missing.

Evidence and fix prompt · HEADER-CSP-UNSAFE-INLINE-STYLE

CSP allows 'unsafe-inline' styles

content-security-policy: default-src 'self'; script-src 'self' 'nonce-YzFkNDM3MmEtZWY5Yi00OGFlLTg5NTAtNmEwMWE2OTFjZmMx' 'strict-dynamic'; style-src 'self' 'unsafe-inline' https://fonts.googleapis.com…

A security scan of this app found the issue below. Investigate and fix it.

## Finding
- Title: CSP allows 'unsafe-inline' styles
- Severity: medium
- Rule: HEADER-CSP-UNSAFE-INLINE-STYLE
- Area: headers
- Observed at path: /
- Header involved: Content-Security-Policy

## What the scanner recorded
```
content-security-policy: default-src 'self'; script-src 'self' 'nonce-YzFkNDM3MmEtZWY5Yi00OGFlLTg5NTAtNmEwMWE2OTFjZmMx' 'strict-dynamic'; style-src 'self' 'unsafe-inline' https://fonts.googleapis.com…
```

## What the scanner saw
Your Content-Security-Policy includes 'unsafe-inline' in style-src. Injected CSS runs — this does not execute scripts, but it is not harmless either.

LOW · Cross-Origin-Embedder-Policy is missing or too open

Evidence and fix prompt · HEADER-COEP-MISSING

Cross-Origin-Embedder-Policy is missing or too open

A security scan of this app found the issue below. Investigate and fix it.

## Finding
- Title: Cross-Origin-Embedder-Policy is missing or too open
- Severity: low
- Rule: HEADER-COEP-MISSING
- Area: headers
- Observed at path: /
- Header involved: Cross-Origin-Embedder-Policy

## What the scanner saw
No Cross-Origin-Embedder-Policy header was returned.

## Why it matters
Without COEP, the browser cannot enable crossOriginIsolated features (SharedArrayBuffer, precise performance.now()). It also leaves embedded cross-origin resources without the extra credentials-stripping the spec provides.

## Suggested direction
Add `Cross-Origin-Embedder-Policy: require-corp`. Third-party images/scripts you embed will need their own CORP or CORS opt-in; `credentialless` is an easier migration path.

## Rules for this fix
1. Reproduce first. Confirm the issue actually exists before changing anything (run the reproduce command above when there is one). If it does not reproduce, say so and stop — do not "fix" a finding you cannot confirm.
2. Make the smallest change that resolves it. Do not refactor unrelated code.
3. Never weaken or remove an existing security check to make this finding go away.
4. If the real fix belongs in hosting or platform configuration rather than code, say exactly what to change and where, instead of forcing a code change.
5. When you are done, explain what you changed and why in one short paragraph a non-developer can understand.

INFO · No reporting endpoints configured

You will never see CSP violations, deprecation reports, or intervention reports in production. Debugging CSP is much harder without this.

Evidence and fix prompt · HEADER-REPORT-TO-MISSING

No reporting endpoints configured

A security scan of this app found the issue below. Investigate and fix it.

## Finding
- Title: No reporting endpoints configured
- Severity: info
- Rule: HEADER-REPORT-TO-MISSING
- Area: reporting
- Observed at path: /
- Header involved: Reporting-Endpoints

## What the scanner saw
Neither `Report-To` nor `Reporting-Endpoints` header is set. CSP `report-uri` and `report-to` directives will silently drop reports.

## Why it matters
You will never see CSP violations, deprecation reports, or intervention reports in production. Debugging CSP is much harder without this.

## Suggested direction
Add `Reporting-Endpoints: default="https://your-endpoint/report"` and wire your CSP `report-to default` to it. Services like report-uri.com or Sentry handle the receiving side.

## Rules for this fix
1. Reproduce first. Confirm the issue actually exists before changing anything (run the reproduce command above when there is one). If it does not reproduce, say so and stop — do not "fix" a finding you cannot confirm.
2. Make the smallest change that resolves it. Do not refactor unrelated code.
3. Never weaken or remove an existing security check to make this finding go away.
4. If the real fix belongs in hosting or platform configuration rather than code, say exactly what to change and where, instead of forcing a code change.
5. When you are done, explain what you changed and why in one short paragraph a non-developer can understand.

INFO · We could not see which server software version you run. That is not the same as safe.

Hidden versions can still be old ones. Checking the version on the server, or letting us read what your code declares, tells you for sure.

Evidence and fix prompt · EXPOSURE-VERSION-UNKNOWN

UNKNOWN: Server software (Server and X-Powered-By headers)

No software version in the Server or X-Powered-By headers.

A security scan of this app found the issue below. Investigate and fix it.

## What the scanner recorded
```
No software version in the Server or X-Powered-By headers.
```

## What the scanner saw
The site does not say which server software or version it runs, so its headers cannot show whether it is exposed.

## Why it matters
Nobody can tell from here whether this is exposed. UNKNOWN is not safe; it means the check could not see.

INFO · Your website’s framework version has no known serious holes today.

We re-check automatically when new security advisories come out.

Evidence and fix prompt · EXPOSURE-VERSION-OK

OK: Next.js 16.4.3 (Next.js runtime in /_next/static/immutable/chunks/08mq80k63s_7m.js)

/_next/static/immutable/chunks/08mq80k63s_7m.js: …r.exports}u.ab="/ROOT/node_modules/.pnpm/next@16.4.3_@babel+core@7.29.0_@types+node@20.19.39_…

A security scan of this app found the issue below. Investigate and fix it.

## Finding
- Title: OK: Next.js 16.4.3 (Next.js runtime in /_next/static/immutable/chunks/08mq80k63s_7m.js)
- Severity: info
- Rule: EXPOSURE-VERSION-OK
- Area: software-versions
- Observed at path: /

## What the scanner recorded
```
/_next/static/immutable/chunks/08mq80k63s_7m.js: …r.exports}u.ab="/ROOT/node_modules/.pnpm/next@16.4.3_@babel+core@7.29.0_@types+node@20.19.39_…
```

## What the scanner saw
Next.js 16.4.3 (Next.js runtime in /_next/static/immutable/chunks/08mq80k63s_7m.js) is on a supported branch with no known vulnerable range covering it.

## Why it matters
No known exposure for this version today.

## Suggested direction
Nothing to do now. ShipSafe re-checks when new advisories land.

## Rules for this fix
1. Reproduce first. Confirm the issue actually exists before changing anything (run the reproduce command above when there is one). If it does not reproduce, say so and stop — do not "fix" a finding you cannot confirm.
2. Make the smallest change that resolves it. Do not refactor unrelated code.
3. Never weaken or remove an existing security check to make this finding go away.
4. If the real fix belongs in hosting or platform configuration rather than code, say exactly what to change and where, instead of forcing a code change.
5. When you are done, explain what you changed and why in one short paragraph a non-developer can understand.

INFO · Traffic between your users and your app may not always be encrypted.

On open Wi-Fi, unencrypted traffic can be read or altered by whoever runs the network. Browsers also warn users away from sites that get this wrong.

Evidence and fix prompt · TLS-ISSUER

TLS issuer: Let's Encrypt

issuer: Let's Encrypt
notAfter: Jan 19 22:40:26 2027 GMT

A security scan of this app found the issue below. Investigate and fix it.

## Finding
- Title: TLS issuer: Let's Encrypt
- Severity: info
- Rule: TLS-ISSUER
- Area: tls

## What the scanner recorded
```
issuer: Let's Encrypt
notAfter: Jan 19 22:40:26 2027 GMT
```

## What the scanner saw
Certificate issued by Let's Encrypt.

## Why it matters
Informational only.

## Rules for this fix
1. Reproduce first. Confirm the issue actually exists before changing anything (run the reproduce command above when there is one). If it does not reproduce, say so and stop — do not "fix" a finding you cannot confirm.
2. Make the smallest change that resolves it. Do not refactor unrelated code.
3. Never weaken or remove an existing security check to make this finding go away.
4. If the real fix belongs in hosting or platform configuration rather than code, say exactly what to change and where, instead of forcing a code change.
5. When you are done, explain what you changed and why in one short paragraph a non-developer can understand.

INFO · Traffic between your users and your app may not always be encrypted.

On open Wi-Fi, unencrypted traffic can be read or altered by whoever runs the network. Browsers also warn users away from sites that get this wrong.

Evidence and fix prompt · TLS-CHAIN-DEPTH

TLS certificate chain length: 3

chain length: 3

A security scan of this app found the issue below. Investigate and fix it.

## Finding
- Title: TLS certificate chain length: 3
- Severity: info
- Rule: TLS-CHAIN-DEPTH
- Area: tls

## What the scanner recorded
```
chain length: 3
```

## What the scanner saw
The certificate chain presented by the server is 3 certificate(s) long before the root store takes over.

## Why it matters
Informational only. A typical web cert is depth 2 (leaf + intermediate). Deeper chains add latency on new connections because each intermediate adds bytes to the handshake.

## Rules for this fix
1. Reproduce first. Confirm the issue actually exists before changing anything (run the reproduce command above when there is one). If it does not reproduce, say so and stop — do not "fix" a finding you cannot confirm.
2. Make the smallest change that resolves it. Do not refactor unrelated code.
3. Never weaken or remove an existing security check to make this finding go away.
4. If the real fix belongs in hosting or platform configuration rather than code, say exactly what to change and where, instead of forcing a code change.
5. When you are done, explain what you changed and why in one short paragraph a non-developer can understand.

INFO · Traffic between your users and your app may not always be encrypted.

On open Wi-Fi, unencrypted traffic can be read or altered by whoever runs the network. Browsers also warn users away from sites that get this wrong.

Evidence and fix prompt · TLS-HSTS-PRELOAD-NOT-SUBMITTED

HSTS header is preload-ready but domain is not in the preload list

strict-transport-security: max-age=63072000; includeSubDomains; preload

A security scan of this app found the issue below. Investigate and fix it.

## What the scanner recorded
```
strict-transport-security: max-age=63072000; includeSubDomains; preload
```

## Why it matters
Minor — without preload submission, the first visit on a new network is still cleartext-eligible for users who haven't visited before.

## Suggested direction
Submit your domain at https://hstspreload.org. Note that preload is a one-way door: removal takes months.

INFO · Someone who finds a problem has no way to tell you.

A security.txt file is a public note saying "report problems here". Without it, the person who finds a hole may just post it instead.

Evidence and fix prompt · EXPOSURE-SECURITY-TXT-MISSING

No /.well-known/security.txt

/.well-known/security.txt

GET https://seatrial.io/.well-known/security.txt
HTTP/1.1 404 Not Found

A security scan of this app found the issue below. Investigate and fix it.

## Finding
- Title: No /.well-known/security.txt
- Severity: info
- Rule: EXPOSURE-SECURITY-TXT-MISSING
- Area: exposure
- Observed at path: /.well-known/security.txt

## What the scanner recorded
```
GET https://seatrial.io/.well-known/security.txt
HTTP/1.1 404 Not Found
```

## What the scanner saw
The site does not publish a security.txt file. This is an informational nudge, not a vulnerability.

## Why it matters
Researchers who find bugs have no canonical way to reach your security team — disclosure often ends up on Twitter instead.

## Suggested direction
Publish `/.well-known/security.txt` with at least `Contact:` and `Expires:` fields. See https://securitytxt.org.

## Rules for this fix
1. Reproduce first. Confirm the issue actually exists before changing anything (run the reproduce command above when there is one). If it does not reproduce, say so and stop — do not "fix" a finding you cannot confirm.
2. Make the smallest change that resolves it. Do not refactor unrelated code.
3. Never weaken or remove an existing security check to make this finding go away.
4. If the real fix belongs in hosting or platform configuration rather than code, say exactly what to change and where, instead of forcing a code change.
5. When you are done, explain what you changed and why in one short paragraph a non-developer can understand.

INFO · Your site is telling attackers more about itself than it needs to.

Knowing exactly what software you run lets attackers pick attacks that are known to work on it. Revealing less costs nothing.

Evidence and fix prompt · FINGERPRINT

Framework fingerprint: Next.js (hosted on Vercel)

server: Vercel
_next/static or __NEXT_DATA__ in HTML

A security scan of this app found the issue below. Investigate and fix it.

## Finding
- Title: Framework fingerprint: Next.js (hosted on Vercel)
- Severity: info
- Rule: FINGERPRINT
- Area: fingerprint
- Observed at path: /

## What the scanner recorded
```
server: Vercel
_next/static or __NEXT_DATA__ in HTML
```

## What the scanner saw
Response headers and HTML indicate the site is built with Next.js and served by Vercel.

## Why it matters
Not a vulnerability — informational. Some frameworks have specific hardening guides.

## Rules for this fix
1. Reproduce first. Confirm the issue actually exists before changing anything (run the reproduce command above when there is one). If it does not reproduce, say so and stop — do not "fix" a finding you cannot confirm.
2. Make the smallest change that resolves it. Do not refactor unrelated code.
3. Never weaken or remove an existing security check to make this finding go away.
4. If the real fix belongs in hosting or platform configuration rather than code, say exactly what to change and where, instead of forcing a code change.
5. When you are done, explain what you changed and why in one short paragraph a non-developer can understand.

Release check · 11/2/2026, 3:03:41 AM UTC

gtsbahamas/shipsafe-web · https://seatrial.io · revision 5058f47e

Website, exposure and versions: ran — 10 findings and notes
Open redirects: ran — Existing URL scanner; GET only, outside redirects never followed. Individual coverage notes apply.
Safe confirmation and combined risks: ran — 2 proof attempts, 0 combined risks
Agent wiring and prompt injection review: ran — 0 static findings. Live agent conversations are not run: they require POST/sign-in, beyond this read-only target.
OWASP benchmark: not-run — No benchmark receipt supplied for this revision; no score claimed.

Coverage and proof

Public GET/HEAD only. No sign-in, submitted forms, active agent conversations, customer sites or customer repositories.
Mail/domain registry checks are not run: they contact outside services. Database hosts, OPTIONS and Convex POST queries are refused.
Exposure/version assessment uses the scanner’s bundled advisory baseline when current feed storage cannot be read.
Refused by self-target scope: GET https://seatrial.io (action route)

0 combined risks; 2 proof steps recorded.

{
  "chains": [],
  "proof": [
    {
      "ruleId": "EXPOSURE-VERSION-UNKNOWN",
      "host": "seatrial.io",
      "path": "/",
      "at": "2026-11-02T03:03:48.329Z",
      "outcome": "not-run",
      "detail": "finding carries no version string to confirm"
    },
    {
      "ruleId": "EXPOSURE-VERSION-OK",
      "host": "seatrial.io",
      "path": "/",
      "at": "2026-11-02T03:03:48.329Z",
      "outcome": "not-run",
      "detail": "finding carries no version string to confirm"
    }
  ]
}

10 findings and coverage notes.

MEDIUM · Your pages have no backstop if a malicious script sneaks in.

This protection does not stop the break-in itself; it limits the damage when one happens. Right now that safety net is missing.

Evidence and fix prompt · HEADER-CSP-UNSAFE-INLINE-STYLE

CSP allows 'unsafe-inline' styles

content-security-policy: default-src 'self'; script-src 'self' 'nonce-NzNiNjAxNDItNzc3ZS00OTRkLTkzZTctZWM3YWJkMWQ0ZTU5' 'strict-dynamic'; style-src 'self' 'unsafe-inline' https://fonts.googleapis.com…

A security scan of this app found the issue below. Investigate and fix it.

## Finding
- Title: CSP allows 'unsafe-inline' styles
- Severity: medium
- Rule: HEADER-CSP-UNSAFE-INLINE-STYLE
- Area: headers
- Observed at path: /
- Header involved: Content-Security-Policy

## What the scanner recorded
```
content-security-policy: default-src 'self'; script-src 'self' 'nonce-NzNiNjAxNDItNzc3ZS00OTRkLTkzZTctZWM3YWJkMWQ0ZTU5' 'strict-dynamic'; style-src 'self' 'unsafe-inline' https://fonts.googleapis.com…
```

## What the scanner saw
Your Content-Security-Policy includes 'unsafe-inline' in style-src. Injected CSS runs — this does not execute scripts, but it is not harmless either.

LOW · Cross-Origin-Embedder-Policy is missing or too open

Evidence and fix prompt · HEADER-COEP-MISSING

Cross-Origin-Embedder-Policy is missing or too open

A security scan of this app found the issue below. Investigate and fix it.

## Finding
- Title: Cross-Origin-Embedder-Policy is missing or too open
- Severity: low
- Rule: HEADER-COEP-MISSING
- Area: headers
- Observed at path: /
- Header involved: Cross-Origin-Embedder-Policy

## What the scanner saw
No Cross-Origin-Embedder-Policy header was returned.

## Why it matters
Without COEP, the browser cannot enable crossOriginIsolated features (SharedArrayBuffer, precise performance.now()). It also leaves embedded cross-origin resources without the extra credentials-stripping the spec provides.

## Suggested direction
Add `Cross-Origin-Embedder-Policy: require-corp`. Third-party images/scripts you embed will need their own CORP or CORS opt-in; `credentialless` is an easier migration path.

## Rules for this fix
1. Reproduce first. Confirm the issue actually exists before changing anything (run the reproduce command above when there is one). If it does not reproduce, say so and stop — do not "fix" a finding you cannot confirm.
2. Make the smallest change that resolves it. Do not refactor unrelated code.
3. Never weaken or remove an existing security check to make this finding go away.
4. If the real fix belongs in hosting or platform configuration rather than code, say exactly what to change and where, instead of forcing a code change.
5. When you are done, explain what you changed and why in one short paragraph a non-developer can understand.

INFO · No reporting endpoints configured

You will never see CSP violations, deprecation reports, or intervention reports in production. Debugging CSP is much harder without this.

Evidence and fix prompt · HEADER-REPORT-TO-MISSING

No reporting endpoints configured

A security scan of this app found the issue below. Investigate and fix it.

## Finding
- Title: No reporting endpoints configured
- Severity: info
- Rule: HEADER-REPORT-TO-MISSING
- Area: reporting
- Observed at path: /
- Header involved: Reporting-Endpoints

## What the scanner saw
Neither `Report-To` nor `Reporting-Endpoints` header is set. CSP `report-uri` and `report-to` directives will silently drop reports.

## Why it matters
You will never see CSP violations, deprecation reports, or intervention reports in production. Debugging CSP is much harder without this.

## Suggested direction
Add `Reporting-Endpoints: default="https://your-endpoint/report"` and wire your CSP `report-to default` to it. Services like report-uri.com or Sentry handle the receiving side.

## Rules for this fix
1. Reproduce first. Confirm the issue actually exists before changing anything (run the reproduce command above when there is one). If it does not reproduce, say so and stop — do not "fix" a finding you cannot confirm.
2. Make the smallest change that resolves it. Do not refactor unrelated code.
3. Never weaken or remove an existing security check to make this finding go away.
4. If the real fix belongs in hosting or platform configuration rather than code, say exactly what to change and where, instead of forcing a code change.
5. When you are done, explain what you changed and why in one short paragraph a non-developer can understand.

INFO · We could not see which server software version you run. That is not the same as safe.

Hidden versions can still be old ones. Checking the version on the server, or letting us read what your code declares, tells you for sure.

Evidence and fix prompt · EXPOSURE-VERSION-UNKNOWN

UNKNOWN: Server software (Server and X-Powered-By headers)

No software version in the Server or X-Powered-By headers.

A security scan of this app found the issue below. Investigate and fix it.

## What the scanner recorded
```
No software version in the Server or X-Powered-By headers.
```

## What the scanner saw
The site does not say which server software or version it runs, so its headers cannot show whether it is exposed.

## Why it matters
Nobody can tell from here whether this is exposed. UNKNOWN is not safe; it means the check could not see.

INFO · Your website’s framework version has no known serious holes today.

We re-check automatically when new security advisories come out.

Evidence and fix prompt · EXPOSURE-VERSION-OK

OK: Next.js 16.4.3 (Next.js runtime in /_next/static/immutable/chunks/08mq80k63s_7m.js)

/_next/static/immutable/chunks/08mq80k63s_7m.js: …r.exports}u.ab="/ROOT/node_modules/.pnpm/next@16.4.3_@babel+core@7.29.0_@types+node@20.19.39_…

A security scan of this app found the issue below. Investigate and fix it.

## Finding
- Title: OK: Next.js 16.4.3 (Next.js runtime in /_next/static/immutable/chunks/08mq80k63s_7m.js)
- Severity: info
- Rule: EXPOSURE-VERSION-OK
- Area: software-versions
- Observed at path: /

## What the scanner recorded
```
/_next/static/immutable/chunks/08mq80k63s_7m.js: …r.exports}u.ab="/ROOT/node_modules/.pnpm/next@16.4.3_@babel+core@7.29.0_@types+node@20.19.39_…
```

## What the scanner saw
Next.js 16.4.3 (Next.js runtime in /_next/static/immutable/chunks/08mq80k63s_7m.js) is on a supported branch with no known vulnerable range covering it.

## Why it matters
No known exposure for this version today.

## Suggested direction
Nothing to do now. ShipSafe re-checks when new advisories land.

## Rules for this fix
1. Reproduce first. Confirm the issue actually exists before changing anything (run the reproduce command above when there is one). If it does not reproduce, say so and stop — do not "fix" a finding you cannot confirm.
2. Make the smallest change that resolves it. Do not refactor unrelated code.
3. Never weaken or remove an existing security check to make this finding go away.
4. If the real fix belongs in hosting or platform configuration rather than code, say exactly what to change and where, instead of forcing a code change.
5. When you are done, explain what you changed and why in one short paragraph a non-developer can understand.

INFO · Traffic between your users and your app may not always be encrypted.

On open Wi-Fi, unencrypted traffic can be read or altered by whoever runs the network. Browsers also warn users away from sites that get this wrong.

Evidence and fix prompt · TLS-ISSUER

TLS issuer: Let's Encrypt

issuer: Let's Encrypt
notAfter: Jan 19 22:40:26 2027 GMT

A security scan of this app found the issue below. Investigate and fix it.

## Finding
- Title: TLS issuer: Let's Encrypt
- Severity: info
- Rule: TLS-ISSUER
- Area: tls

## What the scanner recorded
```
issuer: Let's Encrypt
notAfter: Jan 19 22:40:26 2027 GMT
```

## What the scanner saw
Certificate issued by Let's Encrypt.

## Why it matters
Informational only.

## Rules for this fix
1. Reproduce first. Confirm the issue actually exists before changing anything (run the reproduce command above when there is one). If it does not reproduce, say so and stop — do not "fix" a finding you cannot confirm.
2. Make the smallest change that resolves it. Do not refactor unrelated code.
3. Never weaken or remove an existing security check to make this finding go away.
4. If the real fix belongs in hosting or platform configuration rather than code, say exactly what to change and where, instead of forcing a code change.
5. When you are done, explain what you changed and why in one short paragraph a non-developer can understand.

INFO · Traffic between your users and your app may not always be encrypted.

On open Wi-Fi, unencrypted traffic can be read or altered by whoever runs the network. Browsers also warn users away from sites that get this wrong.

Evidence and fix prompt · TLS-CHAIN-DEPTH

TLS certificate chain length: 3

chain length: 3

A security scan of this app found the issue below. Investigate and fix it.

## Finding
- Title: TLS certificate chain length: 3
- Severity: info
- Rule: TLS-CHAIN-DEPTH
- Area: tls

## What the scanner recorded
```
chain length: 3
```

## What the scanner saw
The certificate chain presented by the server is 3 certificate(s) long before the root store takes over.

## Why it matters
Informational only. A typical web cert is depth 2 (leaf + intermediate). Deeper chains add latency on new connections because each intermediate adds bytes to the handshake.

## Rules for this fix
1. Reproduce first. Confirm the issue actually exists before changing anything (run the reproduce command above when there is one). If it does not reproduce, say so and stop — do not "fix" a finding you cannot confirm.
2. Make the smallest change that resolves it. Do not refactor unrelated code.
3. Never weaken or remove an existing security check to make this finding go away.
4. If the real fix belongs in hosting or platform configuration rather than code, say exactly what to change and where, instead of forcing a code change.
5. When you are done, explain what you changed and why in one short paragraph a non-developer can understand.

INFO · Traffic between your users and your app may not always be encrypted.

On open Wi-Fi, unencrypted traffic can be read or altered by whoever runs the network. Browsers also warn users away from sites that get this wrong.

Evidence and fix prompt · TLS-HSTS-PRELOAD-NOT-SUBMITTED

HSTS header is preload-ready but domain is not in the preload list

strict-transport-security: max-age=63072000; includeSubDomains; preload

A security scan of this app found the issue below. Investigate and fix it.

## What the scanner recorded
```
strict-transport-security: max-age=63072000; includeSubDomains; preload
```

## Why it matters
Minor — without preload submission, the first visit on a new network is still cleartext-eligible for users who haven't visited before.

## Suggested direction
Submit your domain at https://hstspreload.org. Note that preload is a one-way door: removal takes months.

INFO · Someone who finds a problem has no way to tell you.

A security.txt file is a public note saying "report problems here". Without it, the person who finds a hole may just post it instead.

Evidence and fix prompt · EXPOSURE-SECURITY-TXT-MISSING

No /.well-known/security.txt

/.well-known/security.txt

GET https://seatrial.io/.well-known/security.txt
HTTP/1.1 404 Not Found

A security scan of this app found the issue below. Investigate and fix it.

## Finding
- Title: No /.well-known/security.txt
- Severity: info
- Rule: EXPOSURE-SECURITY-TXT-MISSING
- Area: exposure
- Observed at path: /.well-known/security.txt

## What the scanner recorded
```
GET https://seatrial.io/.well-known/security.txt
HTTP/1.1 404 Not Found
```

## What the scanner saw
The site does not publish a security.txt file. This is an informational nudge, not a vulnerability.

## Why it matters
Researchers who find bugs have no canonical way to reach your security team — disclosure often ends up on Twitter instead.

## Suggested direction
Publish `/.well-known/security.txt` with at least `Contact:` and `Expires:` fields. See https://securitytxt.org.

## Rules for this fix
1. Reproduce first. Confirm the issue actually exists before changing anything (run the reproduce command above when there is one). If it does not reproduce, say so and stop — do not "fix" a finding you cannot confirm.
2. Make the smallest change that resolves it. Do not refactor unrelated code.
3. Never weaken or remove an existing security check to make this finding go away.
4. If the real fix belongs in hosting or platform configuration rather than code, say exactly what to change and where, instead of forcing a code change.
5. When you are done, explain what you changed and why in one short paragraph a non-developer can understand.

INFO · Your site is telling attackers more about itself than it needs to.

Knowing exactly what software you run lets attackers pick attacks that are known to work on it. Revealing less costs nothing.

Evidence and fix prompt · FINGERPRINT

Framework fingerprint: Next.js (hosted on Vercel)

server: Vercel
_next/static or __NEXT_DATA__ in HTML

A security scan of this app found the issue below. Investigate and fix it.

## Finding
- Title: Framework fingerprint: Next.js (hosted on Vercel)
- Severity: info
- Rule: FINGERPRINT
- Area: fingerprint
- Observed at path: /

## What the scanner recorded
```
server: Vercel
_next/static or __NEXT_DATA__ in HTML
```

## What the scanner saw
Response headers and HTML indicate the site is built with Next.js and served by Vercel.

## Why it matters
Not a vulnerability — informational. Some frameworks have specific hardening guides.

## Rules for this fix
1. Reproduce first. Confirm the issue actually exists before changing anything (run the reproduce command above when there is one). If it does not reproduce, say so and stop — do not "fix" a finding you cannot confirm.
2. Make the smallest change that resolves it. Do not refactor unrelated code.
3. Never weaken or remove an existing security check to make this finding go away.
4. If the real fix belongs in hosting or platform configuration rather than code, say exactly what to change and where, instead of forcing a code change.
5. When you are done, explain what you changed and why in one short paragraph a non-developer can understand.

First baseline · 11/2/2026, 2:58:36 AM UTC

gtsbahamas/shipsafe-web · https://seatrial.io · revision 238d6ba1

Website, exposure and versions: not-run — The firewall blocked the website; TLS observations only. Not assessed, not passed.
Open redirects: not-run — The firewall blocked the website; TLS observations only. Not assessed, not passed.
Safe confirmation and combined risks: not-run — The firewall blocked the website; TLS observations only. Not assessed, not passed.
Agent wiring and prompt injection review: ran — 0 static findings. Live agent conversations are not run: they require POST/sign-in, beyond this read-only target.
OWASP benchmark: not-run — No benchmark receipt supplied for this revision; no score claimed.

Coverage and proof

Public GET/HEAD only. No sign-in, submitted forms, active agent conversations, customer sites or customer repositories.
Mail/domain registry checks are not run: they contact outside services. Database hosts, OPTIONS and Convex POST queries are refused.
Exposure/version assessment uses the scanner’s bundled advisory baseline when current feed storage cannot be read.

0 combined risks; 0 proof steps recorded.

{
  "chains": [],
  "proof": []
}

3 findings and coverage notes.

INFO · We could not check this part, so it is not known to be safe.

The scan did not get the answer it needed. This is a gap in what we saw, not a pass. Running the scan again usually fills it.

Evidence and fix prompt · SCAN-BLOCKED-BY-FIREWALL

Scan blocked — Vercel answered instead of the site

HTTP/1.1 403 Forbidden
server: Vercel
content-type: text/html; charset=utf-8
body is the "Vercel Security Checkpoint" page

A security scan of this app found the issue below. Investigate and fix it.

## Finding
- Title: Scan blocked — Vercel answered instead of the site
- Severity: info
- Rule: SCAN-BLOCKED-BY-FIREWALL
- Area: coverage
- Observed at path: /

## What the scanner recorded
```
HTTP/1.1 403 Forbidden
server: Vercel
content-type: text/html; charset=utf-8
body is the "Vercel Security Checkpoint" page
```

## What the scanner saw
The front page returned HTTP 403 with a Vercel challenge page, not the application's page. Real browsers pass this by running JavaScript; Seatrial's identified scanner does not. Every check that reads the front page (security headers, cookies, CORS, framework fingerprint, the Supabase/RLS check) could not run. TLS checks still ran because they never read the page. There are no header findings in this report because none could be assessed — not because the site passed.

## Why it matters
This report says almost nothing about the application. A clean result here means "not assessed", not "safe". Search-engine crawlers, link previews and AI assistants are being turned away the same way.

INFO · Traffic between your users and your app may not always be encrypted.

On open Wi-Fi, unencrypted traffic can be read or altered by whoever runs the network. Browsers also warn users away from sites that get this wrong.

Evidence and fix prompt · TLS-ISSUER

TLS issuer: Let's Encrypt

issuer: Let's Encrypt
notAfter: Jan 19 22:40:26 2027 GMT

A security scan of this app found the issue below. Investigate and fix it.

## Finding
- Title: TLS issuer: Let's Encrypt
- Severity: info
- Rule: TLS-ISSUER
- Area: tls

## What the scanner recorded
```
issuer: Let's Encrypt
notAfter: Jan 19 22:40:26 2027 GMT
```

## What the scanner saw
Certificate issued by Let's Encrypt.

## Why it matters
Informational only.

## Rules for this fix
1. Reproduce first. Confirm the issue actually exists before changing anything (run the reproduce command above when there is one). If it does not reproduce, say so and stop — do not "fix" a finding you cannot confirm.
2. Make the smallest change that resolves it. Do not refactor unrelated code.
3. Never weaken or remove an existing security check to make this finding go away.
4. If the real fix belongs in hosting or platform configuration rather than code, say exactly what to change and where, instead of forcing a code change.
5. When you are done, explain what you changed and why in one short paragraph a non-developer can understand.

INFO · Traffic between your users and your app may not always be encrypted.

On open Wi-Fi, unencrypted traffic can be read or altered by whoever runs the network. Browsers also warn users away from sites that get this wrong.

Evidence and fix prompt · TLS-CHAIN-DEPTH

TLS certificate chain length: 3

chain length: 3

A security scan of this app found the issue below. Investigate and fix it.

## Finding
- Title: TLS certificate chain length: 3
- Severity: info
- Rule: TLS-CHAIN-DEPTH
- Area: tls

## What the scanner recorded
```
chain length: 3
```

## What the scanner saw
The certificate chain presented by the server is 3 certificate(s) long before the root store takes over.

## Why it matters
Informational only. A typical web cert is depth 2 (leaf + intermediate). Deeper chains add latency on new connections because each intermediate adds bytes to the handshake.

## Rules for this fix
1. Reproduce first. Confirm the issue actually exists before changing anything (run the reproduce command above when there is one). If it does not reproduce, say so and stop — do not "fix" a finding you cannot confirm.
2. Make the smallest change that resolves it. Do not refactor unrelated code.
3. Never weaken or remove an existing security check to make this finding go away.
4. If the real fix belongs in hosting or platform configuration rather than code, say exactly what to change and where, instead of forcing a code change.
5. When you are done, explain what you changed and why in one short paragraph a non-developer can understand.