Security policy

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 catalog with an optional account system bolted beside it. Understanding what is actually deployed saves you time on findings that cannot apply here, and points you at the part that can:

• No database behind the catalog. Every catalog, template, policy and article route is compiled from JSON manifests at build time, so there is nothing to inject into, dump or enumerate on any of them.
• Accounts exist, and they are in scope. This bullet said the opposite until 19 September 2026 and it was wrong: since 11 September 2026 the site has an optional account system — email-and-password and Google sign-in, sessions, a profile, saved files and an admin route — backed by a hosted libSQL database. Authentication, authorisation, session handling and the account API routes are all fair game. Test them against your own account only; see the out-of-scope list below for what is not allowed while you do.
• Server-side secrets exist, scoped to those account features. The deployment holds the credentials its authentication and database access need. Nothing in a catalog render reads them, and none of them are exposed to the browser.
• 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.
• Three endpoints accept input, and this bullet said “exactly one” until 19 September 2026. POST /api/demo-submit backs the on-site form demos: 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. /api/auth/* and /api/saved are the account features and are in scope as described above. /api/v1/* is read-only.
• 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.
• The account system: /api/auth/*, /api/saved, /sign-in, /sign-up, /forgot-password, /reset-password, /account and /admin. Authentication bypass, session handling, account linking, privilege escalation to the admin role, and reading or writing another account’s saved files are all in scope. Use accounts you created yourself.
• 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 an analytics script can load without consent where consent is required. Note that the Mediavine Journey advertising tag is deliberately unconditional server HTML on every route as of 19 September 2026, and its own consent prompt governs what it may store — that is by design and not a finding. See the cookie policy.

Out of scope

These are either deliberate design decisions, third-party behaviour, or classes of finding that do not apply to the static half of this site. 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' in script-src. Production permits string evaluation. This bullet named Adsterra as the reason until 19 September 2026, which was out of date: the token was added for the display loader of the ad network this site ran before it moved to Mediavine, which evaluated a string to register an impression. Advertising here is Mediavine Journey now, and whether its wrapper relies on the same permission has not been measured. CSP cannot scope the token to one origin, so it is a broad string-based permission whichever third-party script uses it, and the site offsets that by never rendering untrusted code or markup. An unexpected evaluation error is still worth investigating rather than dismissing as benign third-party noise: on the retired stack it left a creative visibly rendered while silently stopping its measurement beacon.
• Missing CSP reporting endpoint. A report collector would have to receive and store reports from every visitor, which is a data-collection surface this site deliberately does not have.
• Findings inside third-party advertising or analytics frames, which we neither author nor control. Report those to Mediavine or Google respectively.
• 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