Security — Noteshik

TLS 1.2+ Encryption in Transit

All communication between the app and our servers is encrypted using TLS 1.2 or higher. Your notes never travel over unencrypted connections — all HTTP requests are automatically redirected to HTTPS.

Certificates issued by Let's Encrypt with automatic renewal via Certbot.

bcrypt Password Hashing

Passwords are hashed using bcrypt with a cost factor of 12 before being stored. bcrypt is deliberately slow and includes automatic salting, making it resistant to brute-force and rainbow table attacks.

We cannot recover your password — if you forget it, you must reset it via email.

Short-Lived JWT Sessions

Authentication uses JSON Web Tokens (JWT) signed with a server-side secret using HMAC-SHA256. Tokens have a short expiry window to minimize the impact of token theft. Tokens are stored only on your device.

The JWT secret is stored in environment variables — never in source code.

Rate Limiting

Login and registration endpoints are rate-limited to 10 requests per 15 minutes per IP address to prevent brute-force and credential-stuffing attacks. API endpoints are limited to 100 requests per 15 minutes. Upload endpoints are capped at 20 per hour.

Input Sanitization

All user input is sanitized server-side before processing to prevent Cross-Site Scripting (XSS) and injection attacks. All database queries use parameterized statements — no string interpolation of user data into SQL.

HTTP Security Headers

Our API server uses Helmet.js to set strict HTTP security headers including Content-Security-Policy, X-Frame-Options: DENY, X-Content-Type-Options: nosniff, Strict-Transport-Security, and Referrer-Policy.

CSRF Protection

State-changing API requests (create, update, delete) require a valid CSRF token in addition to JWT authentication, protecting against Cross-Site Request Forgery attacks from malicious websites.

Email Verification

New accounts require email verification before accessing the service. This prevents account registration with fake or stolen email addresses and reduces spam and abuse on the platform.

Technical Security Specifications

TLS Version TLS 1.2 minimum, TLS 1.3 preferred. SSLv3, TLS 1.0, and TLS 1.1 are disabled.

Password Algorithm bcrypt, cost factor 12, with automatic unique salt per password.

JWT Signing Algorithm HMAC-SHA256 (HS256). Tokens carry id, email, and exp claims only.

Auth Rate Limit 10 requests / 15-minute window per IP for /auth/login and /auth/register.

General API Rate Limit 100 requests / 15-minute window per IP for all other /api/* endpoints.

SQL Injection Prevention Parameterized queries via node-postgres (pg library). No raw string interpolation.

XSS Prevention Server-side input sanitization middleware. CSP headers block inline script execution from non-self origins.

CORS Policy Strict allowlist of permitted origins. Access-Control-Allow-Origin is never set to wildcard (*) on authenticated endpoints.

Request Body Limit 50 MB maximum body size, enforced before parsing. Prevents memory exhaustion attacks.

Directory Traversal Static file server blocks any path containing .. sequences.

Infrastructure Security

Server Environment

Noteshik runs on a dedicated VPS provided by Contabo GmbH, Frankfurt, Germany — not shared hosting. No other applications share the server's resources.
The application runs as a non-root user managed by PM2 (process manager). If the application process is compromised, it cannot gain root privileges on the host system.
The operating system is kept up to date with security patches. Automatic security updates are enabled.

SSH & Remote Access

SSH access is key-based authentication only. Password-based SSH is disabled (PasswordAuthentication no in sshd_config).
SSH root login is restricted. Administrative access uses a dedicated user with sudo privileges.
The default SSH port is changed from 22 to reduce automated brute-force scan noise.
A firewall (UFW) blocks all inbound connections except HTTPS (443), HTTP (80 redirected to HTTPS), and SSH.

Database Security

The PostgreSQL database is not exposed to the public internet. It only accepts connections from localhost (127.0.0.1). There is no external database port open.
The database uses a dedicated application user with minimum required privileges (SELECT, INSERT, UPDATE, DELETE on specific tables only — no SUPERUSER, CREATEDB, or CREATEROLE).
Database credentials are stored as environment variables in a .env file with restricted file permissions, not in source code.
Database backups are created daily and stored encrypted.

Reverse Proxy & Network

Nginx acts as a reverse proxy in front of the Node.js application. Nginx handles TLS termination, HTTP-to-HTTPS redirection, and security header enforcement.
The Node.js application server binds to 127.0.0.1 only — not publicly accessible directly.
Server tokens (Nginx version information) are suppressed to reduce information disclosure.

Data Protection Practices

Secrets Management

JWT secret key: Stored in environment variable (JWT_SECRET). Never committed to source control. Rotated periodically.
Database password: Stored in environment variable (DB_PASSWORD). Never appears in any log file or error message.
Groq API key: Stored in environment variable (GROQ_API_KEY). Used only server-side — never exposed to clients.
All secrets are excluded from version control via .gitignore.

Audio & Voice Data

Voice recordings submitted for transcription are transmitted to our server over HTTPS.
The audio is immediately forwarded to Groq's Whisper API without being written to disk.
We do not store, log, or retain audio files at any stage. The audio exists only in server memory for the duration of the API call.
If the Groq API call fails, the audio data is discarded — it is never retried using stored copies.

Note Content

Note content is stored in the PostgreSQL database, protected by the database access controls described above.
Support staff and developers do not have access to your note content during normal operations. Accessing user notes would require deliberate action and leave audit trails.
We do not read, scan, index for advertising, or analyze your note content for any purpose other than returning it to you.

Deleted Data

When you delete a note, it is immediately soft-deleted (flagged as deleted and removed from your view).
Soft-deleted notes are permanently purged from the database and all backups within 30 days.
When you delete your account, all associated data (notes, folders, tags, images, device records) is deleted immediately; any residual backups are purged within 30 days.

Backup & Disaster Recovery

Daily automated backups: The PostgreSQL database is backed up daily using pg_dump. Backups are compressed and stored with restricted access.
Backup retention: Daily backups are retained for 14 days. Weekly backups are retained for 3 months.
Backup testing: Backups are periodically restored to a test environment to verify integrity and recoverability.
Offline-first architecture: Noteshik stores a complete copy of your notes locally on your device. Even in the event of server downtime, you retain access to all your notes. Your device is itself a backup.
Recovery time objective: In the event of server failure, we target restoration of service within 4 hours using backups and infrastructure snapshots.

Security Incident Response

In the event of a confirmed security incident affecting user data, we follow this response procedure:

Contain: Immediately isolate the affected system and revoke potentially compromised credentials.
Assess: Determine the scope and nature of the breach — which data was affected, which users are impacted.
Notify: If personal data was exposed, affected users will be notified via email within 72 hours of confirming the breach, as required by GDPR Article 33. The notification will describe what happened, what data was exposed, and what steps you should take.
Remediate: Fix the root cause vulnerability, force password resets for affected accounts if credentials may be compromised, rotate affected secrets.
Post-mortem: Document what happened, why it happened, and what changes were made to prevent recurrence.

We will never attempt to conceal a data breach or delay notification beyond legal requirements.

What We Don't Do

We do not store plaintext passwords at any point.
We do not log your note content in server logs or error reports.
We do not retain voice recordings after transcription is complete.
We do not expose your database to the public internet.
We do not use your account for testing or development — we use separate test accounts.
We do not share your credentials, API tokens, or secrets with third parties.
We do not use third-party analytics or crash-reporting SDKs that could access your note content.
We do not permit our hosting provider (Contabo) to access application data — they provide only raw server resources.

🔒 Responsible Disclosure Program

Found a security vulnerability in Noteshik? We want to know. Please report it to us before disclosing publicly so we can fix it and protect our users.

Report to: support@9gg.app (use the contact form)

What to include: A clear description of the vulnerability, steps to reproduce it, your assessment of the impact, and any proof-of-concept code if available.

What to expect: We will acknowledge receipt within 48 hours. We will investigate and keep you updated on progress. We aim to resolve confirmed critical vulnerabilities within 7 days and high-severity within 30 days.

Safe Harbor: We will not take legal action against researchers who follow responsible disclosure principles — who report privately, avoid accessing user data beyond what is necessary to demonstrate the vulnerability, and give us reasonable time to fix the issue before publishing.

Scope: The Noteshik backend API (noteshik.9gg.app), mobile app authentication flows, and data storage mechanisms. Out of scope: social engineering, physical attacks, denial of service testing, and third-party services (Groq, Contabo).

Security at Noteshik