Responsible Disclosure Policy

Last Updated: July 2026

Examify values the security of our platform and welcomes responsible security research and vulnerability reporting from ethical hackers, security researchers, and the broader cybersecurity community.

This policy outlines how to report security vulnerabilities responsibly and describes what to expect when you do.

1. Scope

1.1 What Is in Scope

We welcome reports of security vulnerabilities affecting:

• Examify Web Platform: The main website, web application, and APIs at examify.com or associated domains
• Examify Mobile Apps: iOS and Android native applications distributed through official app stores
• User Data: Unauthorized access, disclosure, or modification of user accounts, performance data, or personal information
• Authentication: Weaknesses in login, session management, password reset, or authorization mechanisms
• API Security: REST API vulnerabilities, token leakage, or broken access controls
• Encryption: Weaknesses in data encryption, SSL/TLS configuration, or certificate issues
• Database Security: SQL injection, NoSQL injection, or unauthorized database access
• Infrastructure: Server misconfiguration, exposed credentials, or cloud storage leaks
• Malware/Injection: Cross-site scripting (XSS), cross-site request forgery (CSRF), or code injection flaws
• Business Logic: Flaws in exam access controls, subscription verification, or payment processing
• Third-Party Integrations: Vulnerabilities in Auth0, WooCommerce, payment processors, or other integrated services that directly impact Examify's security

1.2 What Is Out of Scope

We do not accept reports on:

• Personal Security Issues: Compromised user accounts due to weak user-chosen passwords (advise users to use strong passwords instead)
• Default Credentials: Uses of unchanged default usernames/passwords on user-owned systems
• Social Engineering: Phishing or social engineering attacks (report to appropriate authorities instead)
• Publicly Disclosed Vulnerabilities: Issues already publicly known or previously reported
• Denial of Service (DoS/DDoS): Unless the vulnerability is a fundamental design flaw (not merely resource exhaustion)
• Third-Party Services: Vulnerabilities in external services (Auth0, WooCommerce, payment processors) not directly under Examify's control — report to the service provider
• Content or Medical Accuracy: Inaccurate exam questions, medical content errors, or educational quality concerns (use the feedback/submission system instead)
• Spam or Abuse Reports: Report abusive users through the support system
• Privacy Policy Violations: Concerns about how data is used (contact us directly; this does not require vulnerability disclosure)
• Rate Limiting Bypass: Unless it enables unauthorized access or data breach
• Non-Functional Issues: Bugs that do not affect security (e.g., typos, layout issues, broken links)

If your report falls outside our scope, we may still investigate if it raises genuine security concerns, but public disclosure policies may differ.

2. How to Report a Vulnerability

2.1 Email Reporting (Preferred)

Send vulnerability reports to:

info@alexiatechnology.com

Email Subject Line: SECURITY VULNERABILITY REPORT: [Brief Description]

Example: SECURITY VULNERABILITY REPORT: SQL Injection in Question Search API

2.2 What to Include in Your Report

Please provide as much detail as possible (but do NOT include working exploits or live proof-of-concept code that could be misused):

Information	Purpose
Vulnerability Title	Clear, concise summary (e.g., "XSS in User Profile Page")
Vulnerability Type	Classification (e.g., CWE-79 Cross-site Scripting, CWE-89 SQL Injection)
Severity	Your assessment: Critical, High, Medium, Low
CVSS Score (optional)	CVSS v3.1 score if available (e.g., CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H)
Affected Component	Which part of Examify (e.g., Web login, Mobile app, API endpoint, Admin panel)
Steps to Reproduce	Detailed, step-by-step instructions to verify the vulnerability (without executing the exploit)
Impact Description	What could an attacker do? (e.g., "View other users' exam scores," "Modify user data")
Technical Details	Root cause analysis, code snippets (sanitized), or network requests (do NOT include working exploit code)
Proof of Concept (POC)	Optional: Pseudocode or generic example showing the flaw (NOT a functional exploit)
Your Contact Information	Name, email, phone (optional), preferred timeline for disclosure
Disclosure Preference	Do you want public credit? Preferred name/handle for attribution?

2.3 Do NOT Do This

3. What to Expect From Us

3.1 Response Timeline

Timeframe	Action
Within 24 hours	Initial acknowledgment of receipt; we confirm we received your report
Within 5-7 days	Initial assessment; we confirm validity or request clarification
Within 30 days (Critical)	Fix deployed for critical vulnerabilities; we notify you
Within 60 days (High)	Fix deployed for high-severity vulnerabilities
Within 90 days (Medium/Low)	Fix deployed for medium and low-severity issues
Within 90 days of fix	We release a security advisory (if appropriate); you may publicly disclose

3.2 Communication

We will:

• Acknowledge receipt of your report within 24 hours
• Keep you updated on investigation progress
• Inform you when a fix is deployed
• Share details about the vulnerability (if you wish)
• Discuss appropriate timing for public disclosure

3.3 Validation

If we determine your report is not a valid security issue, we will explain why and suggest alternative channels (e.g., bug report for non-security issues, feedback system for content concerns).

4. Safe Harbor

4.1 Legal Protection

We will not pursue legal action against security researchers who:

• Report vulnerabilities in good faith
• Do not access data or systems beyond what is necessary to demonstrate the vulnerability
• Do not exploit the vulnerability for personal gain
• Do not cause unauthorized harm to users or systems
• Do not violate any applicable laws
• Follow this Responsible Disclosure Policy

4.2 Exemptions

Safe harbor does not apply if you:

• Publicly disclose the vulnerability without our agreement
• Demand payment as a condition of disclosing the vulnerability
• Disclose vulnerabilities to other parties before reporting to us
• Access unauthorized data beyond what is necessary to demonstrate the issue
• Conduct testing beyond the scope of this policy
• Violate local laws or regulations

4.3 Coordination with Law Enforcement

If a vulnerability report involves criminal activity, we may be obligated to report it to law enforcement. However, if you report a security issue in good faith per this policy, we will make reasonable efforts to avoid implicating you.

5. Coordinated Disclosure Policy

5.1 Timing

Once a fix is deployed and verified, you may publicly disclose the vulnerability. We will notify you when public disclosure is appropriate. Ideal timeline:

1. Vulnerability reported to Examify
2. Examify investigates and develops a fix
3. Fix is deployed to production and verified
4. Examify prepares a security advisory (if necessary)
5. Examify confirms public disclosure is safe
6. You may disclose publicly (with our approval)

5.2 Credit and Attribution

Researchers who report valid vulnerabilities will receive:

• Public Credit: Your name/handle in our security advisory (optional; you can request anonymity)
• Acknowledgment Email: Official thank-you and recognition of your contribution
• Security Advisory Link: We'll provide a link to reference if you publish your own writeup
• Verification of Fix: We can help you verify that the fix properly addresses the vulnerability

5.3 Embargo Period

We ask researchers to maintain an embargo (not publicly disclose) until:

• A fix is deployed to production, AND
• We have publicly released a security advisory or patch notes, AND
• We have notified you that public disclosure is safe

Typical embargo is 30-90 days depending on severity. We will discuss the appropriate timeline with you.

5.4 Exception: Active Exploitation

If we discover that a reported vulnerability is actively being exploited in the wild, we may publicly disclose and release a fix immediately, even if our normal timeline has not elapsed. We will notify you before doing so.

6. Security Testing Guidelines

6.1 Authorized Testing

You may conduct security testing on Examify if you:

• Use your own test account (not other users' accounts)
• Limit testing to the vulnerability being reported
• Do not access, modify, or delete other users' data
• Do not conduct load/stress testing or denial-of-service attacks
• Respect rate limiting and access controls
• Do not scan or enumerate the infrastructure without permission

6.2 Unauthorized Testing

Do not conduct:

• Penetration testing without prior written authorization
• Vulnerability scanning beyond the specific issue being reported
• Network reconnaissance or port scanning
• Access to other users' data, even to prove a point
• Brute-force attacks or credential stuffing
• Denial-of-service testing

6.3 Requesting Authorization for Extended Testing

If you are a professional security researcher and wish to conduct broader security testing, contact us at info@alexiatechnology.com with:

• Your background and experience
• Scope of testing you propose
• Timeline and methodology
• References from previous authorized testing

We may grant written authorization for professional security assessments.

7. Questions About This Policy

If you have questions about this Responsible Disclosure Policy or need clarification, contact:

Examify Security Team
Email: info@alexiatechnology.com
Subject Line: "SECURITY POLICY QUESTION"

We will respond within 2-3 business days.

8. Acknowledgment