Security

Effective 5 September 2026 · Operated by SSCVeers

This page describes how SSCVeers protects your account and data, which protections it does not have, and how to tell us if you find a problem. It is written from the code, not from a template.

No certifications, no audit

SSCVeers holds no security certification. It has not been penetration tested, has had no third-party security audit, and is not certified under SOC 2, ISO 27001 or any comparable scheme. If you need those assurances, they do not exist here.

PCI-DSS is not applicable, for a specific reason rather than by omission: no card or bank credential ever reaches SSCVeers. Payment happens entirely inside your own UPI app.

What is in place

Accounts and sign-in

Your password is held by the authentication provider, not by SSCVeers. This project stores no password and no password hash of its own, so there is nothing here for an attacker to crack.
Sign-up requires a code sent to your email address, so an account cannot be created on an address you do not control.
Changing your password requires your current password first, even when you are already signed in. A borrowed session cannot be used to lock you out of your own account.
Sessions expire. When one does, you are returned to sign-in with an explanation rather than a silent failure.
The sign-in page refuses to redirect you off-site after login, including through the backslash trick that defeats a naive check.

Access to data

Every API endpoint resolves who is calling before it does anything, and returns only rows belonging to that account.
The admin area is gated twice: once before the page renders and again inside each admin endpoint against the role stored in the database. A frontend check alone is never the gate.
Every administrative action — approving or rejecting a payment, changing a user's limits — is written to an audit log with who did it and when.
Database queries use bound parameters, so values you type are never spliced into SQL text.
Row-level security policies exist in the database as a second layer. Be aware of the honest caveat: the application connects as the table owner, so those policies do not constrain the application itself — the checks in the endpoints are the real gate, and the policies protect against direct access with a lesser key.

Payments and uploads

The amount for a plan is read from the database, never from the request, so the price cannot be tampered with by editing the page.
A payment reference can be used exactly once, enforced by the database rather than by a check that could be raced.
Payment submissions are limited to three per account per day.
Payment screenshots are stored in private storage and are read only by an administrator reviewing that payment. They are never placed on a public URL.
Uploads accept only PDF and plain text, and only up to 10 MB.

Error handling

Failures show you a plain sentence. Database messages, stack traces, file paths and internal identifiers are logged on the server and not sent to your browser.

Abuse limits and browser protections

The sign-in form temporarily locks an email out after repeated failed attempts, and slows down a burst of attempts from one network. The error never says which part was wrong or that a lock is in effect. Sign-in itself is handled by the authentication provider, which applies its own limits.
The costly features — the AI tutor, uploads, PDF notes, study plans and the data export — are rate limited on top of the per-plan usage caps.
The site sends a Content-Security-Policy, refuses to be framed by other sites, and in production tells browsers to use HTTPS only (HSTS).

What is not in place

Stated plainly, because a security page that lists only strengths is not useful:

No two-factor authentication. A password and access to your email are all that protect your account.
No CSRF token. State-changing requests are authenticated by the session cookie alone; there is no separate anti-forgery token.
No CAPTCHA. The limits above slow automated abuse down, but nothing asks you to prove you are human.
No claim about encryption or backups. Data lives with the providers named in the Privacy Policy, and whatever they do at rest and in backup is theirs, not something SSCVeers configures or can promise on their behalf.
No intrusion detection or alerting. There is no monitoring that would notice an attack in progress.
No breach-notification commitment with a stated deadline. If your data were exposed you would be told, but this page does not invent a number of hours it has no process to meet.

Practical advice that follows from the above: use a password you do not use anywhere else, keep your email account secure, and do not put anything in an upload or a chat that would be damaging if it were exposed.

Responsible disclosure

If you find a vulnerability, please tell us before telling anyone else. Reports are welcome and will not be met with hostility.

Where to send it

Email kumarpushu74@gmail.com. Include what you found, the steps to reproduce it, and what an attacker could do with it.

What we ask of you

Give us a reasonable chance to fix it before you disclose it publicly.
Test only against your own account. Do not access, modify or delete another person's data — if a flaw would let you, describe it rather than demonstrating it at someone else's expense.
Do not run denial-of-service tests, automated scanners at volume, or anything that degrades the service for students using it.
Do not use social engineering against the operator or any provider.
Stop as soon as you have confirmed the issue, and tell us what you accessed.

What you can expect

Your report will be read by the person who operates SSCVeers. This page does not promise a response time, a severity rating process, a fix deadline, a bounty or any payment — none of those exists, and inventing one would be worse than saying so. What is promised is that a report made in good faith and within the limits above will not be met with a legal complaint.