Responsible Disclosure

Scope

In scope: movahedi.ca, the public site of Movahedi Solutions. Out of scope: everything else. That includes, without exception for this policy: client systems; systems belonging to any other party; any system, account, or service that is not movahedi.ca, even if it is linked from movahedi.ca or mentioned on movahedi.ca; and internal tools, inboxes, or accounts used by the company, unless they are part of the public movahedi.ca site itself. If you are unsure whether something is in scope, ask first at mohammad@movahedi.ca, and wait for a reply before testing. A report about an out-of-scope system will not be treated as a report under this policy.

What to include in a report

A useful report lets the company reproduce the issue and judge its effect without guessing. Include:

1. What was observed. Describe the issue in plain terms, and what you expected to happen instead.
2. Page affected. Give the full page address on movahedi.ca where the issue was seen.
3. Date and time. Give the date and time you observed the issue, with your time zone.
4. Steps to reproduce. List the steps you took, in order, so the company can repeat them.
5. Effect. Describe what the issue lets a visitor do, or what information it exposes, based only on what you actually observed. Do not speculate beyond what you saw.
6. Evidence that stays inside scope. Screenshots or short notes are welcome when they show only the public movahedi.ca page and the issue itself.
7. Contact for follow-up. Give an address where the company can reach you with questions. This is used only for follow-up on the report.

Use the Security Issue Report form to structure the report.

What not to test

Do not test anything outside movahedi.ca. In particular, do not: test client systems, whether or not you believe a client uses movahedi.ca or is connected to the company; test systems belonging to other parties, including vendors, hosts, or services linked from the site; attempt to access accounts, inboxes, or internal tools; attempt to change, delete, or disrupt data, pages, or services; run automated scans, brute-force attempts, denial-of-service testing, or social engineering against the company, its staff, or its contacts; or use a reported issue to access data beyond what is needed to demonstrate the issue itself, and stop once the issue is confirmed. Testing that goes beyond confirming an issue on a public movahedi.ca page is outside this policy, even if the intent was to help.

What not to include in a report

Do not include: client confidential material (if you believe material in your report could be client confidential, leave it out and say, in general terms, that you withheld something and why, without including it); material from any other party's system; credentials, tokens, private keys, or personal information belonging to anyone other than yourself, and personal information about yourself beyond what is needed for follow-up contact; or content you obtained by testing outside scope, or by accessing an account or system you were not invited to use. The report form includes a confirmation checkbox for this rule. Do not submit the form unless the confirmation is true for your report.

How reports are handled

Reports go to mohammad@movahedi.ca. The company reviews reports in the order received, and prioritizes by the effect described and verified on movahedi.ca. Handling steps:

1. Receipt. The report is received at mohammad@movahedi.ca.
2. Review. The company reviews the steps, the page affected, and the evidence provided.
3. Verification. The company attempts to reproduce the issue on movahedi.ca.
4. Fix or decision. If verified, the company fixes the issue or records a decision about it, based on the verified effect.
5. Re-check. The company re-checks the reported page after the fix, using the steps in the report.
6. Closure. The reporter is told the outcome for their report, as described below.

How this works in practice, in general terms. A reporter completes the form, reviews the prepared email in their own email program, and sends it. The company reviews the steps and page, attempts to reproduce the issue, fixes it or records a decision, re-checks the page, and tells the reporter the outcome. This is a generic process description. It names no reporter, no issue, and no outcome.

Acknowledgement and re-check process

Acknowledgement: the company aims to acknowledge a report sent to mohammad@movahedi.ca, so the reporter knows it was received. This page does not state a fixed acknowledgement time, because none is promised here. Acknowledgement means receipt and review, not confirmation that the issue is verified, and not a promise of a bounty or a fix date. If a report is missing the page affected, the steps, or a follow-up contact, the acknowledgement will ask for the missing item. The company does not promise a fix date on this page, because the time needed depends on what is verified. A report that cannot be reproduced from its steps will be answered with the questions needed to reproduce it.

Re-check process: the reporter may re-check the same public movahedi.ca page after the company says a fix is in place, using only the same in-scope steps from the original report; send the re-check result to mohammad@movahedi.ca, with the original report details, the date and time of the re-check, and whether the issue still appears; if the issue still appears, the company reviews the re-check result and repeats the verification and fix steps; if the issue no longer appears, the report is closed as fixed on the re-checked page, and the reporter is told so. Re-checking does not extend scope. A reporter who disagrees with a decision can reply with the additional in-scope evidence that supports a different result, and the company will review that evidence under the same process.

Bounty

No bounty is offered under this policy. A bounty applies only if it is separately approved and funded, in writing, for a specific report or a specific period, and the terms of that approval are stated to the reporter before testing for that bounty begins. Until such an approval exists and is communicated, no payment, reward, or credit beyond acknowledgement and closure notice should be expected for a report. This page itself is not an approval, and it does not create a bounty program.

Good faith

Reports made in good faith, inside scope, and within the testing limits on this page are welcome. Good faith means: testing only movahedi.ca, stopping once an issue is confirmed, not disrupting the site or its visitors, not accessing data beyond what demonstrates the issue, and not including client confidential material or other parties' material in the report.

Disclosure acknowledgements

Movahedi Solutions thanks researchers who report security issues on movahedi.ca in good faith and inside scope. Reports are reviewed in the order received, and the reporter is told the outcome for their report, as described above. No researcher report is listed here yet. When a real report arrives, it will be added here, with the reporter's permission, with its date and its remediation. Reports go to mohammad@movahedi.ca, using the route above. A security contact file is published at movahedi.ca/.well-known/security.txt, with contact and a policy link to this page. The formal policy is the Vulnerability Disclosure Policy.

Report an issue

Use the Security Issue Report form. Form destination: mohammad@movahedi.ca. Related page: Security Practices.

Scope and limits, stated briefly

This page does not give legal advice, and it does not authorize testing outside scope. If a proposed test would break the limits on this page, do not run it, and ask first at mohammad@movahedi.ca.