How to report a security bug in an app we built for you

TL;DR — If you think you found a security bug, send it by email to the security contact in your support agreement or your usual agency support address with the subject line "Security report: <your app name>". Include the app URL, exact steps to reproduce, what account type you used, screenshots, and whether the issue is still live; do not post the bug in a public ticket, chat channel, or app store review. Reading time: ~5 min

Goal

When you finish, our team will have a complete private security report with enough detail to reproduce the issue, assess risk, and reply with a case number or acknowledgment without asking you for basic missing information.

Prerequisites

• Your company email account you normally use to work with us
• The correct contact address from your contract, statement of work, or support handbook; if you do not have one, use your usual agency support email and put Security report: at the start of the subject line
• The app name and production URL, for example https://app.example.com
• A browser you can use to reproduce the issue again, such as Chrome, Edge, Firefox, or Safari
• Any screenshots or screen recordings that show the problem
• The exact time you saw the issue, including your time zone, for example 2026-10-30 14:20 UTC+1
• If login is involved: the account type you used, for example admin, manager, or customer; do not send your password
• Optional but helpful: the browser version; in Chrome, open Menu → Help → About Google Chrome

Steps

Step 1: Find the private place to send the report

Use the security contact listed in your paperwork first. If you do not have a dedicated security address, use your normal support address and mark it clearly as a security report.

Exact subject line to use:

Security report: <your app name>

If your company uses a support portal instead of email, open your provider's dashboard and look for a private ticket option, for example Support portal → New ticket → Security or Help → Contact support. If there is no security-specific option, choose the most private support form available and paste the same subject line above.

What you should see when this succeeds: your email is sent or your private ticket is created, and you have a sent-message copy or ticket number.

Step 2: Do not report it in a public place

Do not put security details into any public or broad-access channel.

Avoid these places:

- Public issue tracker
- Shared team chat channel with external guests
- App store review
- Social media post
- Website contact form that does not send you a copy

If you already posted it publicly, send a second private message immediately with the public link and this exact first line:

I accidentally shared a possible security issue publicly. Please treat this as urgent and advise on removal.

What you should see when this succeeds: the report exists only in a private email thread or private ticket.

Step 3: Collect the minimum details we need to reproduce it

Copy this template into your email or ticket and replace the bracketed parts.

App name: [your app name]
Production URL: [full URL, for example https://app.example.com/account]
Environment: [production / staging / test]
Reported by: [your name, company, email, phone if urgent]
Date and time seen: [YYYY-MM-DD HH:MM and time zone]
Severity guess: [critical / high / medium / low / not sure]
Summary: [one sentence describing the issue]

Steps to reproduce:
1. [first click or action]
2. [second click or action]
3. [exact input you entered]
4. [what happened]

Expected result:
[what you expected to happen instead]

Actual result:
[what actually happened]

Account type used:
[admin / manager / customer / anonymous / not sure]

Can you still reproduce it?
[yes / no / sometimes]

Affected data:
[customer data / payment data / files / no data seen / not sure]

Attachments:
[screenshot names or screen recording names]

What you should see when this succeeds: your draft contains exact clicks, exact URLs, and exact results instead of a general description like "security seems weak".

Step 4: Add safe evidence, but do not send secrets

Attach proof that helps us reproduce the issue, but remove anything that could create a second incident.

Send these items if you have them:

- Screenshot of the page URL and visible result
- Screen recording of the steps
- The exact text of any error message
- The browser version, for example Chrome 141.0.x
- The user role you were signed in as

Do not send these items:

- Your password
- MFA (multi-factor authentication) codes
- Full credit card numbers
- Full private keys or API keys
- Large database exports

If a secret is visible in a screenshot, replace it before sending with this exact text:

[REDACTED SECRET]

What you should see when this succeeds: your attachments prove the issue without exposing passwords, codes, or keys.

Step 5: If the issue is active, tell us whether you need immediate containment

If the bug is currently exposing data, allowing unauthorized access, or disrupting service, say that clearly in the first lines of the message.

Use one of these exact lines at the top of your report:

Active exposure: I can currently access data I should not be able to see.

Active account issue: I can currently log in as another user or bypass login.

Active service issue: The app is currently unavailable or behaving unsafely for users.

What you should see when this succeeds: the urgency is obvious before anyone opens attachments.

Step 6: Send the report and keep the app state unchanged if possible

Send the email or submit the private ticket.

After sending, do not keep testing aggressively. Specifically, stop after you have enough proof to show the issue once.

Use this exact closing line:

Please confirm receipt of this security report and reply with the case number or next step.

What you should see when this succeeds: you receive an acknowledgment, auto-reply, or ticket number you can refer to later.

Verify it works

Check all of the following:

- The report was sent to a private support or security address
- The subject starts with: Security report:
- The message includes the full URL, exact steps, expected result, and actual result
- The message does not include your password, MFA code, or raw secrets
- You received a sent-email copy, auto-reply, or ticket number

If you used email, verify in your mail client that the message is in Sent. If you used a portal, verify the ticket appears in My requests, My tickets, or the equivalent view in your provider's dashboard.

Expected result: you have a private record of the report and enough detail in it that our team can begin triage without asking you what page, what account type, or what steps you used.

Common pitfalls

Reporting it in a public ticket or chat

Mistake: Posting the bug in a shared channel, public issue tracker, or broad-access help desk queue.

Symptom: More people than necessary can see the issue, and the report may need to be removed before triage starts.

Fix: Re-send the same report privately with the subject Security report: <your app name> and ask for the public post to be removed.

Sending only a screenshot with no steps

Mistake: Attaching an image of the problem but not saying what you clicked or typed.

Symptom: We cannot reproduce the issue, so the first reply asks for more details and loses time.

Fix: Add the Steps to reproduce, Expected result, and Actual result sections from the template above.

Including passwords or MFA codes

Mistake: Sending login secrets because they seem helpful.

Symptom: The report itself becomes sensitive, and we may have to ask you to rotate (replace) the credential before continuing.

Fix: Remove the secret, replace it with [REDACTED SECRET], and send the account email plus account type instead.

Not saying whether the issue is still live

Mistake: Reporting a bug without saying if it still happens now.

Symptom: Triage starts with clarification questions like "Can you still reproduce this?" instead of containment or investigation.

Fix: Add Can you still reproduce it? yes / no / sometimes near the top of the report.

Testing too much after you confirm the bug

Mistake: Continuing to explore the issue after you already proved it once.

Symptom: Extra logs, possible service impact, or accidental access to more data than needed.

Fix: Stop after one clear proof, send the report, and wait for instructions unless we ask you to verify something specific.

This article was written by an AI system and published pending human review. Verify anything you intend to act on.