Vulnerability disclosure
If you have found a way to break the authentication or authorization this platform provides, we want to hear about it. This page says what is in scope, what we ask of you, and what you can expect back. No response time is promised.
On this page
Draft
Status
Last reviewed 5 October 2026. TDACorp Identity is pre-production. The response intentions, safe harbour and recognition wording on this page are policy rather than code facts, and are pending confirmation by the owner. Where this page describes the platform, the statement was checked against the repository.
How to report
Email security@tdacorp.in. The same address is published at /.well-known/security.txt in the RFC 9116 format, so a scanner or an automated triage pipeline can find it without reading this page.
| Item | Value |
|---|---|
| Contact | security@tdacorp.in |
| Machine-readable contact file | /.well-known/security.txt (RFC 9116) |
Canonical field | https://identity.tdacorp.in/.well-known/security.txt |
Policy field | https://identity.tdacorp.in/trust/vulnerability-disclosure |
Preferred-Languages field | en |
Expires field | 2027-02-20T00:00:00.000Z |
Encryption field | Not present: TDACorp publishes no PGP key |
Acknowledgments field | Not present: there is no acknowledgements page |
| Bug bounty | None |
RFC 9116 makes the Expires field mandatory so that a contact address which has quietly stopped working fails loudly. The file is kept short-dated on purpose and is refreshed before it lapses.
What to include
A report is much faster to reproduce when it carries the following.
| Include | Why it helps |
|---|---|
| The exact URL or endpoint, and the request that triggers it | We can find the code path without guessing. |
| The steps, in order, starting from a signed-out browser or a fresh token | Avoids hidden state such as an existing session or a cached consent. |
| What an attacker gets out of it | A bypass that yields nothing and a bypass that yields another person's session are triaged very differently. |
| The account you tested with and the approximate time in UTC | We can find the same events in our logs and audit trail. |
| Anything you captured: requests, responses, a short screen recording, a proof-of-concept script | Evidence beats description. |
| Whether you want to be named | The default is that you are not (see Recognition). |
Encryption of reports
TDACorp publishes no PGP key, so there is nothing to encrypt to. If the finding is severe enough that sending it in cleartext worries you, send a one-line description and we will arrange a channel. We do not have a purpose-built secure upload portal.
Scope
The scope is everything served from the identity host. The sign-in, registration, recovery and account pages are the Next.js web app. The OAuth 2.0 and OpenID Connect endpoints, /auth/v1, /v1/me, /admin/v1, /authz/v1 and /ssf/v1 are served by identityd, which the web app mounts in process behind the same host.
In scope
| Area | Examples | Notes |
|---|---|---|
| Sign-in and registration | Sign-in, self-registration, email verification, magic links, 8-digit email codes | Includes the login transaction cookie binding. |
| Account recovery | Recovery start, the 24-hour hold, recovery link and same-browser device cookie | Recovery links last 15 minutes. |
| Second factors | Passkeys (WebAuthn), authenticator (TOTP) enrolment and verification, recovery codes, step-up re-authentication | Step-up window is 10 minutes. |
| Account pages | Profile, security, sessions and devices, connected apps, activity, data export and deactivation, access tokens | Authorization failures count (see below). |
| OAuth 2.0 and OIDC provider | Discovery and key documents under /.well-known, pushed authorization requests, authorize, token, introspection, revocation, logout | Includes DPoP and resource-indicator handling. |
| Browser and account API | /auth/v1, /v1/me | Session-cookie or first-party bearer. |
| Administrative API | /admin/v1 | Accepts only tokens issued to the configured admin console client. |
| Authorization decision API | /authz/v1 | Behind a DPoP-bound client_credentials token. |
| Shared Signals | /ssf/v1 | |
| Outbound deliveries | Back-channel logout and webhook deliveries to registered clients | Includes the signing of what we send. |
| Admin console | The separate admin console application, which signs in through identityd over OIDC | Served from its own host, so not named in the published scope. Report it anyway and we will triage it. |
| Session, token and key handling | Cookie attributes, token binding, signing key handling, sealed secrets |
Authorization matters as much as authentication here. A report that one user can read or change another user's data, or that a token or role grants more than it should, is in scope even if nothing was authenticated incorrectly.
Out of scope
| Item | Reason |
|---|---|
| Other TDACorp domains and products | They are separate codebases. Send them to the same address anyway and we will route them, but they are not covered by the response intentions below. |
| Services TDACorp does not operate: our hosting platform, our database and email providers, and the third-party breach corpus we query | Report those to their owners. See the subprocessor register for who they are. |
| Findings that require an already-compromised device, browser extension or mailbox | If an attacker is reading the victim's email, they can start account recovery by design. |
| Missing hardening headers, or deviations from a best-practice checklist, with no demonstrated impact | No security consequence shown. |
| Automated scanner output with no working proof of concept | Not a finding until someone shows it works. |
| Denial of service, load testing, resource exhaustion, and anything that degrades the service for other people | Not permitted at all (see rules of engagement). |
| Social engineering of TDACorp people or of our users, and physical attacks | Not covered. |
| A dependency carrying a known CVE, with no path shown to exploiting it through this application | Dependencies are scanned already. See the security practices. |
| Self-XSS, and clickjacking on pages that change no state | No victim and no state change. |
Rules of engagement
| Do | Do not |
|---|---|
| Test against accounts you created yourself | Test against an account you do not own |
| Stop as soon as you have proof | Pivot, escalate into other users' data, or leave anything behind that keeps access open |
| Use a single record screenshot to prove the finding | Bulk download data: it proves nothing more and creates an incident |
| Use a finding only to write the report | Use a finding for anything other than the report |
| Stop, tell us, and delete your copy if you access personal data by accident | Keep or share personal data you reached by accident |
| Ask first if you are unsure whether something is in scope or a test crosses a line | Assume. Asking will never be held against you. |
| Keep request volume modest and test one account at a time | Run load tests, flood the sign-in or email-sending endpoints, or try to exhaust the email sending limits |
| Report promptly | Publish before we have agreed a date (see Coordinated disclosure) |
Testing accounts
The repository documents no provisioned researcher accounts and no researcher sandbox. Create your own account by self-registration. Registration needs an email address you control, because it sends a verification code and link by email. Things that will affect your testing:
| Behaviour | What it means for you |
|---|---|
| Sign-in and registration are rate limited per network address and per identifier | Repeated attempts are throttled. There is no permanent lockout. |
| Outbound email is capped | Do not trigger email sending in volume. |
| Breached-password checking is applied when you set a password | A common password may be refused. |
| Sessions end after 12 hours idle or 14 days in total | Plan long tests accordingly. |
No separate test environment is offered to researchers, so testing happens against the live pre-production host, which is why the rules above are strict.
What happens next
These are intentions, not a contractual response time. No response time is promised. TDACorp runs no round-the-clock security rotation, so a report filed on a Friday night is read on a working day.
| Stage | What we aim to do |
|---|---|
| Acknowledge | Within three business days. |
| Triage | Within ten business days, tell you whether we reproduced it and how serious we think it is. |
| While open | Update you at least every fourteen days, including when the update is that nothing has changed. |
| Resolution | Tell you when the fix ships, and say plainly if we decide not to fix something and why. |
How a report is handled internally follows the operator runbooks (see Incident response). There is no on-call rota, no ticketing SLA and no dedicated security team described anywhere in the repository, and this page does not imply one.
Severity guidance
We read impact first, not the vulnerability class. This table is how we think about it. It is guidance for conversation with a reporter and is not a scoring standard, a bounty tier or a commitment to a fix time.
| Level | Typical impact | Examples |
|---|---|---|
| Critical | Another person's session or credentials, or forged tokens, with little or no victim action | Taking over another account; minting a valid token for an arbitrary subject; reading another tenant's data; recovering a signing key |
| High | A control meant to stop takeover is bypassed, or sensitive data is exposed with some precondition | Bypassing step-up or second-factor requirements; reading another person's personal-data export; replaying a refresh token without reuse detection |
| Medium | Limited exposure or a bypass that needs substantial victim interaction | Open redirect to an unregistered URI; a missing authorization check on a low-risk read; leaking account existence |
| Low | Defence-in-depth gap with no demonstrated path to impact | Verbose error detail; a header weakness paired with a real but minor effect |
| Informational | No security consequence shown | Best-practice suggestions |
Coordinated disclosure
We ask for ninety days between your report and any public write-up, and we would rather agree a date with you than have one imposed. If we cannot fix something in that time, we will tell you why and agree what is reasonable. If a fix ships sooner, you can publish sooner by agreement.
| Step | Detail |
|---|---|
| You report privately | To security@tdacorp.in. |
| We reproduce and fix | We tell you when the fix ships. |
| We agree a date | Ninety days is the starting point. |
| You publish, if you wish | Tell us whether you want to be named. |
| Material that reaches a support channel | Any HAR file, log bundle or screenshot containing live credentials is handled under the support-material runbook. Please redact credentials yourself where you can. |
Safe harbour
If you make a good-faith effort to follow this policy, TDACorp will treat your research as authorised. We will not pursue or support legal action against you over it, and if a third party mistakes your testing for an attack, we will say publicly that it was authorised.
Two limits, stated plainly.
- This is a commitment TDACorp makes on its own behalf. It cannot waive the rights of our users, our customers, or the providers we run on, and it does not authorise you to access, retain or disclose another person's data.
- This page is a statement of intent, not legal advice and not a contract. If a report is made in bad faith, or the testing rules above are ignored, none of the above applies.
Note
This wording is pending legal review by the owner.
Recognition
TDACorp does not run a paid bug bounty. There is no reward budget and no swag. Tell us in your report whether you want to be named, and we will ask you before naming you anywhere. The default is that we do not. There is no hall of fame page today.
Known issues we do not consider reports
The following are already known, disclosed and tracked, so reporting them again will not produce a new finding. Each is documented in the repository or on the other trust pages. If you can show that one is worse than described, tell us.
| Known item | Where it is stated |
|---|---|
| The pre-production key-management provider is a software provider, not a cloud KMS. Anyone holding both the database and the master key could forge tokens and read wrapped secrets until keys are rotated. | Security practices and the software KMS decision record |
| A password accepted while the breach-check service was unreachable is rechecked only when its owner next signs in with it | Security practices |
| The emails sent for a blocked risky sign-in and for a burst of failed sign-in attempts are rate limited per account | Security practices |
| Audit anchoring is a hand-run operator command, and the scheduled anchoring job is built but not enabled | Security practices |
| Avatars are served as uploaded, including any embedded metadata, and the avatar address is keyed to the account identifier | Security audit residual risks |
| Row-level security rests on settings the application role can set, so it guards against a missing filter, not against SQL injection or a stolen database credential | Security audit residual risks |
| The runtime database login holds both application roles, and invariant guards make use of the platform role audited rather than impossible | Security audit residual risks |
| Federation discovery fetches validate the address and then resolve again (DNS rebinding), reachable only for operator-configured issuers | Security audit residual risks |
| Session lifetime and step-up window organization settings exist but are not yet applied, so every session uses the platform defaults | Security practices |
| The primary database is not in India during pre-production, by owner waiver | Subprocessors |
The admin console sets no script-src directive, because Next.js needs a per-request nonce for inline scripts | Operations reference |
The Vercel edge overwrite of X-Forwarded-For is documented but not yet measured on a live deployment | Operations reference |
If your own account is the problem
If you think someone else is in your account, this platform gives you the controls directly: review and revoke every session, check your activity, and change your credentials, all in your account once you are signed in. Email security@tdacorp.in as well if something looks wrong that you cannot undo yourself.
What this page does not claim
| Not claimed | Detail |
|---|---|
| A response or fix time | The acknowledgement, triage and update intervals are intentions. No response time is promised. |
| A bounty or reward | None exists. |
| Round-the-clock coverage | TDACorp runs no 24x7 security rotation described in the repository. |
| A certified or audited programme | No outside party has verified this process. TDACorp holds no security certification. |
| Legal protection beyond TDACorp's own commitment | Safe harbour binds TDACorp only. It cannot waive third-party rights and is pending legal review by the owner. |
| Coverage of other TDACorp products or vendors | Out of scope as listed above. |
| An encrypted submission channel | There is no PGP key and no upload portal. |
| That the platform is free of vulnerabilities | The disclosure policy exists because we expect to be wrong somewhere. |