Skip to content

Security

How ByteCues secures this website and the information you send us — and how to report a vulnerability. This page describes controls that are in place today; it does not claim certifications or audits that have not been completed.

Last updated: · Version 1.0

The short version

  • The site is a static, prerendered website with a small enquiry API behind it, which keeps the attack surface deliberately small.
  • Traffic is encrypted over HTTPS, protected by strict security headers, rate limiting and bot protection.
  • Enquiry data is minimised, access is restricted, and the database is backed up off the server.
  • Found a vulnerability? We welcome good-faith reports and will not pursue researchers who follow the rules below.

This summary is for convenience. The full text below is what applies.

1. Scope of this page

This page covers bytecues.com and the systems that support it: the web server, the enquiry API, the database, and the systems that research and route enquiries. The DashCues, RecruitCues and WealthCues platforms have their own security practices and disclosure channels, described on their own sites.

2. Website and network security

  • Encryption in transit. The site is served only over HTTPS using TLS 1.2 or 1.3 with a certificate from a public certificate authority; HTTP is redirected to HTTPS and strict transport security (HSTS, including subdomains) tells browsers to refuse insecure connections.
  • Hardened browser security headers. A strict Content Security Policy limits which scripts, connections and frames the site can load (and forbids framing the site by other sites); X-Content-Type-Options: nosniff, X-Frame-Options: DENY, a strict referrer policy and a permissions policy that disables camera, microphone, geolocation and similar features.
  • Small attack surface. Pages are prerendered to static files at build time. There is no server-side rendering runtime, no public admin interface, and no database access from the browser.
  • Self-hosted assets. Fonts and images are served from our own domain, which avoids unnecessary third-party requests.
  • Atomic releases and rollback. Each release is built, checked and swapped in as a unit, and previous releases are kept so a faulty release can be rolled back quickly.

3. Application security

  • Input validation. Every enquiry is validated server-side against a strict schema, with limits on the number and size of fields and on request size.
  • Safe data access. Database queries use parameterised statements, which prevents SQL injection.
  • Abuse protection. Rate limiting is applied at the web server and again in the application. Forms include a hidden honeypot field and, where enabled, Cloudflare Turnstile bot verification.
  • Durable, authenticated hand-off. Each enquiry is stored first, then queued and sent to our CRM over HTTPS using a scoped, revocable API key. Failed deliveries are retried automatically with back-off, so enquiries are not lost.
  • Minimal data. We collect only what an enquiry needs; IP addresses stored with enquiries are one-way hashed; no payment or sensitive personal data is collected on the site.

4. Infrastructure and operations

  • Least privilege. Application services run under dedicated, unprivileged system accounts, not as root.
  • Secrets management. Credentials and API keys are kept in access-restricted configuration files on the server, never in source code, the website build, or the browser.
  • Patching. Automatic security updates are enabled on the operating system, and application dependencies are pinned by lockfile and updated deliberately.
  • Monitoring and logging. Web server and application logs are kept for a limited period (about 14 days) to detect abuse and diagnose incidents.
  • Backups and resilience. The enquiry database is continuously replicated to a separate cloud storage location (AWS, Mumbai region) with 30 days of retention, so we can recover from hardware failure or accidental deletion.

5. Protecting your data

  • Access to enquiry data is limited to people who need it to respond, on a need-to-know basis.
  • Service providers that handle enquiry data (listed in our Privacy Policy) are bound by written terms to protect it and use it only for us.
  • AI safeguards. The AI provider’s API key lives only in server-side configuration, never in the website or the browser. Search queries exclude email addresses and phone numbers, spend and search counts are capped, web content is treated as untrusted, AI output is labelled and reviewed by a person, and the system never sends replies on its own.
  • If a breach affecting your personal information occurs, we will investigate and contain it, and notify affected individuals and the relevant authorities without undue delay and within the time limits the law sets (for example 72 hours to the regulator under the GDPR).

6. Secure development

  • Strongly typed code, static analysis and linting (including accessibility rules) run on every build, and the build fails on type errors.
  • Automated tests cover the enquiry API’s validation and behaviour and the site’s route configuration.
  • A build-time check fails if structured data or placeholder content is wrong, so unfinished content does not ship by accident.
  • Dependencies are locked to exact versions and reviewed when updated.

7. Certifications and audits

ByteCues does not currently hold, and does not claim, SOC 2, ISO/IEC 27001 or similar certifications or attestations for this website. We will list them here only when they have been completed.

8. Reporting a security vulnerability

We welcome reports from security researchers and anyone who finds a weakness in our systems. Please report it to us before disclosing it publicly, so we can fix it and protect people.

How to report

Send your report to: our contact form — please put “Security” in the subject, give only a general description, and we will reply with a secure channel for the technical details

Please include, in as much detail as you can: the type of issue; the affected address (URL) or component; step-by-step instructions to reproduce it; any proof-of-concept; the potential impact; and how to contact you. Please send one vulnerability per report. If you need an encrypted channel, ask and we will arrange one.

In scope

  • bytecues.com and its subdomains that we operate.
  • Typical web vulnerability classes: injection, cross-site scripting, cross-site request forgery, authentication or authorisation bypass, server-side request forgery, path traversal, remote code execution, sensitive-data exposure and security misconfiguration.

Out of scope

  • Third-party services and systems (including cloud providers, email, analytics and AI providers, and linked product sites), even if they appear under our domain — please report those to their owners.
  • Denial-of-service or volumetric testing, brute-force attacks, spam or load testing.
  • Social engineering, phishing or physical attacks against ByteCues people or premises.
  • Findings with no demonstrable security impact: missing best-practice headers where no attack is shown, self-XSS, clickjacking on pages with no sensitive actions, banner or version disclosure, missing SPF/DKIM/DMARC records for non-sending domains, and reports from automated scanners without a validated exploit.
  • Vulnerabilities requiring physical access to a device, a rooted or jailbroken device, or outdated browsers.
  • Issues in a dependency that has been publicly disclosed less than 30 days earlier and for which a patch is not yet available.

Ground rules

  • Test only against accounts and data you own or have explicit permission to use, and use only the minimum access needed to show the issue.
  • Do not access, modify, copy or retain other people’s data. If you accidentally access personal data, stop, do not keep or share it, and tell us.
  • Do not degrade the service, run automated attacks at volume, or use the issue to pivot into other systems.
  • Give us reasonable time to fix the issue before sharing details with anyone else. We will tell you what we need.
  • Do not demand payment or make threats in connection with a report.
  • Comply with applicable law, including sanctions and export laws.

What you can expect from us

  • We will acknowledge your report within 5 business days and keep you informed as we investigate and fix it, using reasonable efforts to remediate valid issues promptly based on severity.
  • We will keep your name and contact details confidential and, with your permission, credit you when the issue is fixed.
  • We will not publicly disclose details of your report without discussing it with you first.
  • ByteCues does not currently operate a paid bug-bounty programme, so we cannot offer monetary rewards, but we are grateful for every responsible report.

Safe harbour

If you act in good faith and follow these rules, we will consider your research authorised, will not pursue or support legal action against you for it, and will work with you to understand and resolve the issue. This does not apply to activity that is unlawful, harms users or our systems, or breaks the rules above, and we cannot bind third parties. If you are unsure whether something is covered, ask us before you test.

9. Your part

  • Check that you are on bytecues.com (the address bar shows HTTPS) before sending information, and be wary of messages that claim to be from ByteCues but ask for passwords or payments — we never ask for these by email or through the enquiry forms.
  • Do not include passwords, payment or identity-document details in an enquiry.
  • Keep your own browser and devices up to date.

10. Changes to this page

We will update this page as our controls change. The “Last updated” date shows the current version. For questions about security that are not vulnerability reports, contact us using the details in our Privacy Policy.


Last updated 8 November 2026 (version 1.0). Related: Privacy Policy · Terms of Use · Cookie Policy.