Security Statement
We take the security of our website, our systems, and the data you share with us seriously. This page describes the technical and organisational controls we have in place.
Responsible Disclosure
If you have discovered a security vulnerability on networkz.in, please report it responsibly before public disclosure. See our Responsible Disclosure Policy for details on how to report and what to expect.
1. Our Commitment to Security
Security is a first-class concern at Networkz, both for our own website and for the client systems we build. We design and operate our infrastructure with security in mind at every layer: transport, hosting, application, access control, and process.
This statement describes our security posture at a high level. We deliberately omit specific technical details that could aid an attacker. This statement is informational and does not constitute a contractual security commitment. Security obligations for client engagements are defined in the relevant Master Services Agreement.
2. Transport Security
- HTTPS everywhere: All traffic to and from networkz.in is served over HTTPS. HTTP requests are automatically redirected to HTTPS.
- TLS version: We support TLS 1.2 and TLS 1.3. Legacy TLS versions (1.0, 1.1) and SSL are disabled.
- HSTS: HTTP Strict Transport Security (HSTS) is enforced to prevent protocol downgrade attacks.
- Modern cipher suites: Cloudflare configures our TLS with modern, forward-secret cipher suites.
3. Infrastructure and Hosting
- Hosting: networkz.in is hosted on Vercel, an enterprise-grade platform with SOC 2 Type 2 compliance.
- CDN and edge security: All traffic is routed through Cloudflare, which provides DDoS mitigation, web application firewall (WAF), and bot management at the edge.
- Database: Contact form submissions are stored in a managed, encrypted PostgreSQL database. The database is not publicly accessible; it is accessed only via our server-side API.
- Encryption at rest: Data stored in our database and object storage is encrypted at rest by the hosting provider.
4. Rate Limiting and Abuse Prevention
- API rate limiting: All public-facing API endpoints, including the contact form submission endpoint, are protected by Redis-based rate limiting via Upstash. This prevents brute-force and spam submission attacks.
- Bot detection: Cloudflare's bot management is active at the edge. Our contact form also implements a server-side honeypot field and submission-timing heuristic to filter automated submissions.
- Input validation: All form inputs are validated on the server side before processing. Client-side validation is supplementary only.
5. Access Controls
- Admin panel: The administrative interface is protected by JWT-based authentication. Tokens have short expiry periods and are not stored in localStorage.
- Principle of least privilege: Access rights to systems, databases, and infrastructure are granted on a need-to-know basis. No shared credentials are used.
- No public database access: Our database is not exposed to the public internet. All access is mediated through our server-side API.
6. Dependency Management
- Regular audits: We run
npm auditregularly to identify known vulnerabilities in our dependency tree. - Patch management: Known vulnerabilities in production dependencies are assessed and patched within a reasonable timeframe based on severity.
- Minimal attack surface: We aim to keep our production dependency footprint small and justified.
7. Secrets Management
- Environment variables: All API keys, database connection strings, JWT signing secrets, and other sensitive credentials are stored as environment variables in our hosting platform. They are never committed to source control.
- No secrets in code: We enforce a policy of zero credentials in source code. Our Git history is reviewed periodically to ensure no secrets have been inadvertently committed.
8. Secure Development Lifecycle
- Code review: All changes to production code are reviewed before deployment.
- OWASP Top 10 awareness: Our development practices are informed by the OWASP Top 10 web application security risks, including SQL injection, XSS, broken authentication, and security misconfiguration.
- Output encoding: User-controlled content is properly encoded before being rendered to prevent XSS.
- Parameterised queries: All database interactions use parameterised queries via Prisma ORM to prevent SQL injection.
- Content Security Policy: HTTP security headers, including Content Security Policy, are configured at the edge.
9. Data Storage and Payment Security
- No payment card data: Networkz does not accept, process, or store payment card information. All payments are made via bank transfer (NEFT/RTGS/IMPS) or UPI, which do not involve transmitting card data through our systems.
- No passwords stored: We do not operate a client portal that requires passwords at this time. Admin credentials are stored as bcrypt hashes.
- Minimal data retention: Contact form submissions are retained for 12 months (non-engaged enquiries) or for the duration of an engagement plus 3 years. See our Privacy Policy for full details.
10. Backup and Recovery
- Database backups: Our managed database provider performs automated daily backups with point-in-time recovery capability.
- Disaster recovery: In the event of a catastrophic failure, we can restore the website and database from backup. Recovery time objective (RTO) and recovery point objective (RPO) depend on the hosting provider's SLA.
- Redundancy: Our website is served from Vercel's global edge network with automatic failover.
11. Incident Response
In the event of a security incident affecting personal data or the availability of our services, we will:
- Investigate the incident promptly upon becoming aware of it;
- Contain and remediate the issue as a priority;
- Notify affected individuals and, where required by law, relevant regulatory authorities within the prescribed timeframes;
- Document the incident and our response, and review our controls to prevent recurrence.
For data breach notification obligations, see our Privacy Policy, Section 14.
12. Responsible Disclosure
We welcome responsible security research on networkz.in. If you have discovered a vulnerability, please report it to us before public disclosure so that we have the opportunity to investigate and remediate.
Please see our full Responsible Disclosure Policy for reporting instructions, what is in and out of scope, expected response times, and our safe harbour statement.
13. Security Contact
For security concerns or vulnerability reports, contact us at: