Reporting a vulnerability

How to tell TDACorp about a security flaw in identity, what makes a good report, what not to do while testing, and where the full policy lives.

On this page

If you found a way to break the sign-in, session, token or authorization behaviour of TDACorp Identity, we want to hear about it. This page is the short version for account owners. The full policy, with scope, rules of engagement, disclosure timing and safe harbour wording, is on the Vulnerability disclosure page, and this page does not repeat it.

Is it a vulnerability or an account problem?#

Two different situations lead people here.

Your situation	Where to go
You found a flaw in identity itself: a way to read another person's data, take over an account, bypass a second step, or forge a token.	Report it as below.
You think your own account was taken over.	If you think your account was taken over. Use the account controls first.
You got a suspicious email.	Recognising a phishing email.
You cannot sign in.	If you are locked out.

The disclosure policy says the same about your own account: the platform gives you the controls directly, to review and revoke sessions, check activity and change credentials. Email the security contact as well if something looks wrong that you cannot undo yourself.

How to report#

Email security@tdacorp.in. The same address is published in a machine-readable file at /.well-known/security.txt on the identity host, so a scanner or a triage tool can find it.

There is no secure upload portal, and the platform publishes no encryption key for reports, so a message to that address is sent in the clear. If the finding is severe enough that this worries you, send a one-line description and say you want to arrange another channel. Please redact live credentials in anything you attach.

What to include#

A report is faster to reproduce when it has these.

The exact page or endpoint and the request or action that triggers it.
The steps, in order, starting from a signed-out browser, so hidden state does not mislead.
What an attacker gets: another person's session, data, or only a minor leak. Impact decides how it is read.
The account you tested with and the approximate time in UTC.
What you captured, such as a short screen recording or a proof-of-concept.
Whether you want to be named. The default is that you are not.

While you test#

The full rules are on the disclosure page. In short:

Test only with accounts you created yourself.
Stop as soon as you have proof. Do not go further into other people's data, and do not bulk download anything.
Keep your request volume modest. Do not run load tests, and do not flood sign-in or email-sending pages.
If you reach someone's personal data by accident, stop, tell us, and delete your copy.
Do not publish before a date is agreed.

You can create your own test account on the registration page when sign-up is open. See Create your account. The platform offers no separate test environment for researchers.

What to expect#

The disclosure page lists intentions for acknowledging, triaging and updating you, and says plainly that no response time is promised and that TDACorp runs no round-the-clock security rotation. It says there is no paid bug bounty. It states a safe harbour for good-faith research and flags that its wording is pending legal review. Read the page itself for the current text, because it is the authority and this summary is not.

What you do not need to report#

The disclosure page lists known issues that are already disclosed and tracked, and out-of-scope items such as scanner output with no working proof, missing hardening headers with no demonstrated impact, denial of service, and social engineering. Check it before you spend time on a write-up.

For the platform's wider security posture#

Security practices describes how credentials, sessions, tokens and second factors are handled, and lists what is not claimed. Incident response describes how incidents are handled. Neither is a promise of any particular outcome.