Bluecoderhub — Security
Security
How we protect bluecoderhub.com and the people who use it, and how to tell us if you find a weakness. Everything described here is what the site does today, not a plan.
01Report a vulnerability
- Use the contact form and choose “Security vulnerability report” as the topic, or use the “Report a vulnerability” button at the end of this page. That puts your report in the security queue, not the general one.
- Include what you can: the affected address or endpoint, the steps to reproduce it, and the impact you believe it has. A proof of concept helps but is not required.
- Please do not open a public issue or publish the problem until we have fixed it.
- The same contact details are published in machine-readable form at /.well-known/security.txt.
02What happens next
- We acknowledge your report within 5 working days.
- Within 15 working days we give you our assessment and the time we expect a fix to take.
- We tell you when the fix ships, and we credit you publicly if you would like us to.
03Scope
- In scope: bluecoderhub.com and its API under /api.
- Out of scope: findings that need a compromised device or browser, scanner output with no demonstrated impact, missing headers with no exploit path, denial of service by traffic volume, social engineering of our team, and physical attacks.
04Rules for testing
- Do not run automated scanners against the live site.
- Do not access, change or delete data that belongs to anyone else. If you reach someone else’s data, stop and report what you found.
- Do not degrade the service for other people.
- Keep what you find confidential until we have fixed it.
05Safe harbour
- If you follow these rules in good faith, we treat your research as authorised by us. We will not bring a civil claim against you for it or report it to the police, and we will work with you to understand and fix the problem.
- We can only speak for Bluecoderhub. We cannot waive the rights of anyone else or bind public authorities, and this promise does not cover anything done outside these rules or outside the scope above.
06Encryption
- Every connection to the site uses TLS. Browsers are told to refuse unencrypted connections for two years, on every subdomain (HSTS, with preload).
- The connection from our servers to the database is also encrypted, with full certificate verification.
- Stored data is encrypted at rest by our database provider. Two-factor secrets are encrypted again by us, with AES-256-GCM.
07Protection in your browser
- A strict Content Security Policy lets pages run scripts only from this site, plus one small inline script pinned by its hash. Injected scripts are refused.
- No third-party scripts, analytics, fonts or embeds are loaded, so nothing outside our control runs on these pages.
- Pages cannot be framed by other sites, browsers are told not to guess content types, and camera, microphone and location access are switched off.
- Windows and resources are isolated from other origins, and the full address of a page is never sent to other sites as a referrer.
08Accounts and access
- There are no public user accounts on this site. Only members of the Bluecoderhub team sign in.
- Passwords are stored only as bcrypt hashes. Team sign-in also needs a code from an authenticator app, and the one-time recovery codes are stored only as hashes.
- The session cookie cannot be read by scripts, is sent only over HTTPS and only to this site, expires after 2 hours, and is revoked on the server when you sign out.
- Repeated failed sign-ins are slowed down per address and per account, across every server.
- Every team action that opens or changes personal data is written to an audit trail.
09How the application is built
- Every request is checked against a strict schema before it is used.
- Every database query uses bound parameters. None is built by joining strings.
- Cross-site request forgery is blocked twice: by the cookie’s SameSite rule, and by an origin check on every request that changes anything.
- Public forms are rate-limited per address. The contact and job application forms also carry a hidden field that catches bots.
- Error responses never include stack traces or internal details, and request logs remove private tokens before they are written.
10Supply chain and operations
- Every change runs the full automated test suite, including security regression tests, and a dependency audit that fails on any known high-severity vulnerability.
- Automated pull requests propose dependency updates every week.
- Passwords, keys and tokens live only in our hosting provider’s encrypted environment settings, never in the code.
- The site runs on managed infrastructure: Vercel for hosting, Neon for the database and Upstash for rate limiting.
- Our database provider keeps a restorable history of the database, so it can be recovered to an earlier point after a failure or an attack.
- Every request to our API is logged and the log is kept for a year, longer than the 180 days CERT-In requires, so an incident can be investigated after the fact.
11If something goes wrong
- We contain the problem first, then investigate using the audit trail and request logs, and fix the cause rather than the symptom.
- If personal data is affected, we tell the people concerned without delay and report to the Data Protection Board of India, as our Privacy Policy sets out.
- We report cyber security incidents to CERT-In, India’s national computer emergency response team, within the time Indian law requires.
This notice is written in plain English to describe how Bluecoderhub currently handles data on this site. It is not a substitute for the reviewed legal document that will replace it before commercial launch.
Last updated: 2026-10-30