Skip to content
Novus Examples

Security policy

Last reviewed: 8 August 2026

This is the human-readable half of our disclosure policy. The machine-readable half is the /.well-known/security.txt record, which points here and lists the same reporting address. If the two ever disagree, treat security.txt as authoritative for where to send a report and this page as authoritative for what happens next.

Not to be confused with the security file category, which is a library of sample-only PKI, JWT, and OAuth fixtures for testing auth tooling. That is product content. This page is policy.

Reporting a vulnerability

Email examples@novusstreamsolutions.com with Security in the subject. English is preferred. A useful report includes:

  • The affected URL or endpoint, and the exact request if one is involved.
  • Reproduction steps a stranger can follow, and what an attacker gains.
  • Your browser or tooling, and any proof-of-concept output.
  • Whether you have shared the finding with anyone else, and when you intend to publish.

Please do not open a public issue, post the details on social media, or include real third-party data in your report. If you need to send something sensitive, say so and we will arrange a channel.

What we commit to

  • Acknowledge within five business days. A human replies; you will not get an autoresponder and then silence.
  • Triage within ten business days with an accept / duplicate / out-of-scope decision and, where we accept, a rough fix window.
  • Fix and deploy confirmed issues as a priority. This site is statically built and deployed from source, so a fix ships as a normal deploy — there is no patch window to wait for.
  • Credit you by name or handle when the fix ships, if you want it. Say so in your report; the default is no attribution.

We do not run a bug-bounty programme and we do not pay for reports. We would rather say that plainly up front than have you discover it after doing the work.

Coordinated disclosure

Report privately first and give us a reasonable window to fix. We ask for 90 days from acknowledgement before public disclosure, and we will usually be much faster than that. If we fix it sooner, publish as soon as the fix is live. If we go quiet or miss the window without explanation, publishing is reasonable — but tell us first.

Safe harbour

We will not pursue or support legal action against research conducted in good faith under this policy. That means: stay within the scope below, stop as soon as you have confirmed a finding, do not access or modify data that is not yours, do not degrade the service for other people, and give us a chance to fix things before going public. Good-faith research that accidentally crosses a line and is reported promptly is still good-faith research.

The architecture, and why it shapes the scope

Novus Examples is a static site. Understanding what is actually deployed saves you time on findings that cannot apply here:

  • No database. There is nothing to inject into, dump, or enumerate. The catalog is a set of JSON manifests compiled into the pages at build time.
  • No accounts, no login, no sessions. There is no authentication or authorisation layer, so there is no privilege to escalate and no session to fixate.
  • No runtime environment variables and no server-side secrets. Nothing deployed holds an API key, a token, or a credential.
  • Static-first content. Catalog, template, policy, and article routes are prerendered and served from a CDN. The faceted browser is server-rendered from validated query values; it does not render query text as HTML or create a file-processing endpoint.
  • Exactly one endpoint accepts input: POST /api/demo-submit, which backs the on-site form demos. It is POST-only, same-origin-only, restricted to form content types, honeypot-guarded, rate-limited, and byte-capped while streaming so a chunked body cannot buffer without bound. It validates and then discards — nothing is stored, emailed, or forwarded.
  • The editors, Studios, and synthetic media generators run in your browser.Files you open and export never leave the device; there is no upload path to attack. Audio and video jobs use disposable workers, bounded recipes, transferred buffers, and revoked object URLs. The Permissions Policy also disables camera, microphone, display capture, geolocation, and other capabilities the product does not need.
  • Downloads are static assets served with Content-Disposition: attachment, nosniff, and a default-src 'none'; sandbox content-security policy, so nothing under /files/ can execute as a document.

In scope

  • https://examples.novusstreamsolutions.com and its response headers, redirects, and caching behaviour.
  • The POST /api/demo-submit endpoint — bypassing its origin, method, content-type, size, or rate-limit checks, or making it retain anything.
  • The download-serving rules for /files/, including any way to get a fixture served inline or executed rather than downloaded.
  • The /files/stream/ exception, which deliberately serves inline with permissive cross-origin headers so external players can fetch manifests and segments. A way to place a non-streaming file type there, or to abuse it as a same-site content vector, is in scope.
  • Stored or reflected script execution anywhere in first-party UI, including file previews and the in-browser editors.
  • The service worker and offline app shell — cache poisoning or scope escape.
  • The consent implementation, if a non-essential script can load without consent where consent is required.

Out of scope

These are either deliberate design decisions, third-party behaviour, or classes of finding that do not apply to an architecture with no backend state. We will close them as informative:

  • Sample keys, certificates, JWTs, and tokens in the library. Every private key, certificate, and token under the security category is generated sample material, labelled SAMPLE, and published on purpose so that parsers and auth harnesses have something to chew on. They are not credentials, they protect nothing, and finding them in the repository is not a leak.
  • Intentionally corrupt, malformed, and edge-case files.A truncated PDF, an invalid JSON document, or a ragged CSV is the product working as designed. Those files are labelled “intentionally corrupt” in both title and description.
  • 'unsafe-inline' in script-src. This is deliberate. A per-request nonce would force dynamic rendering and give up static generation and CDN caching for the entire site. The risk is mitigated architecturally instead: untrusted HTML is never rendered into the document, previews use escaped text or <img>, the editor previews user content only in a sandboxed opaque-origin iframe, and object-src is 'none'. The separate 'wasm-unsafe-eval' source permits pinned media encoders to compile only after Generate.
  • 'unsafe-eval' for Adsterra impression measurement. Production permits string evaluation for the narrow operational purpose of allowing Adsterra's display loader to register impressions. CSP cannot scope this token to one origin, so this is necessarily a broad string-based permission even though its intended use is narrow. The site offsets that browser permission by never rendering untrusted code or markup. Removing it can leave a creative visibly rendered while silently stopping its measurement beacon, so an unexpected evaluation error must be investigated rather than dismissed as benign third-party noise.
  • Missing CSP reporting endpoint. A report collector needs a server to receive reports, which conflicts with having no backend.
  • Findings inside third-party advertising or analytics frames, which we neither author nor control. Report those to Google.
  • Missing headers or configuration on domains we do not operate, and issues in /files/ assets that require the victim to deliberately download and execute a labelled test fixture.
  • Volumetric or denial-of-service testing, automated scanner output with no demonstrated impact, self-XSS, clickjacking on pages with no state-changing action, missing SPF/DMARC on a non-mailing domain, outdated-library reports with no working exploit path, and social engineering or physical attacks against anyone at Novus Stream Solutions.

Testing rules

  • Use your own browser and your own data. There is no one else's data here to reach.
  • Keep automated traffic gentle. The demo endpoint is rate-limited; hammering it proves nothing and degrades a free service for other people.
  • Do not attempt to modify or delete anything, and do not pivot to Novus Stream Solutions infrastructure that is not listed in scope.
  • Stop and report as soon as a finding is confirmed.

Privacy of your report

Reports arrive by email and are read by the people who maintain the site. We keep them only as long as needed to fix and verify the issue. How we handle data generally is covered in the privacy policy; the site itself stores nothing about you on our servers.

Related

Accessibility · Privacy · Terms · Status · Security file fixtures