Vulnerability Disclosure Program

1. CONSENT

Embibe is truly dedicated to protecting data safety and security. One of our founding principles is to “Improve Continuously” which directly translates into our information security program enabling the protection of our internal and external confidential  data as a top priority. The Embibe Security Team acknowledges the valuable role that honest, independent security researchers and bug reporters play in the overall security of connected systems. As a result, we encourage the responsible reporting of any vulnerability that may be present in our web and mobile applications, or company website and services. Embibe is committed to working with security researchers to verify and address potential vulnerabilities that are reported to us. Please review these terms before you test and/or report a vulnerability to Embibe. We will provide a safe harbor to security researchers as long as they adhere to this policy and are acting in good faith.

2. SCOPE

All systems and services associated with domains listed below are in scope (refer 5.1 In Scope).  Likewise, subdomains of each listing, unless explicitly excluded, are always in scope.  Additionally, any website published with a link to this policy shall be considered in scope. If you aren’t sure whether a system or endpoint is in scope or not, contact [email protected] .

Though we develop and maintain other internet-accessible systems or services, we ask that active research and testing only be conducted on the systems and services covered by the scope of this document. If there is a system not in scope that you think merits testing, please contact us to discuss it first. We will increase the scope of this policy over time.

3. POLICY

We will investigate all legitimate reports and make every effort to quickly correct any vulnerability. We ask in return that you:

• Provide details of the vulnerability, including information needed to reproduce and validate the vulnerability and a Proof of Concept (POC)
• Make a good faith effort to avoid privacy violations, destruction of data, and interruption or degradation of our services
• Give the Embibe Security Team a reasonable time to correct the issue before making any information public

3.1. HOW TO REPORT THE VULNERABILITY
Please share details of the suspected vulnerability with the Embibe Security Team by sending an email to  [email protected]. Sharing of vulnerability details outside of our formal reporting process is not permitted and will not result in acceptance by Embibe of your vulnerability report.

3.2. IF YOU ARE A EXISTING CUSTOMER/VENDOR
If you feel your account may have been compromised, or if you suspect fraudulent behavior, do not hesitate to contact the Embibe security team at [email protected]

4. RULES OF ENGAGEMENT

4.1. IF YOU ARE AN EXISTING CUSTOMER/VENDOR
Embibe encourages the responsible and ethical discovery and reporting of vulnerabilities. The following conduct is expressly prohibited:

• When experimenting, please only attack test accounts you control. A PoC unnecessarily involving accounts of other guests or Embibe employees may be disqualified. It’s also best practice to tell us the accounts you are using for testing even when they are under your control;
• Do not run automated scans without checking with us first;
• Do not test the physical security of Embibe offices, employees, equipment, partners, vendors, or contractors;
• Do not test using social engineering techniques (phishing, spear-phishing, pretexting, etc.);
• Do not perform DoS or DDoS attacks. You are welcome and encouraged to look for vulnerabilities that can be leveraged for DoS or DDoS attacks, we just don’t want you actually exploiting the issue outside of a tightly controlled environment;
• Do not, in any way, attack our end users/guests or engage in the trade of stolen user credentials;
• Do not access, or attempt to access, data, information, or physical building units that do not belong to you;
• Do not violate any applicable law or breach any agreements in order to discover vulnerabilities, or otherwise utilizing unethical means to gain access and/or information;
• Only the first reporter is eligible for receiving a reward (refer to the Recognition and Rewards section below).

4.2 TESTING ENVIRONMENTS
It is imperative to take every precaution to prevent a significant impact on production systems. Once a reporter establishes that a vulnerability exists, or encounters any sensitive data, the reporter should stop any further testing and notify us immediately. Please take prior approval for exploiting the vulnerability further. Reporters should not use or exploit to compromise or exfiltrate data, establish command line access and/or persistence, or use/exploit to “pivot” to other systems.

4.3 NON-­QUALIFYING VULNERABILITIES
Low severity, purely theoretical and best-practice issues do not qualify for submission. Here are some examples:

• Descriptive error messages (e.g., Stack Traces, application or server errors)
• Theoretical subdomain takeovers with no supporting evidence
• HTTP 404 codes/pages or other HTTP non-200 codes/pages
• Information leakage, fingerprinting/banner disclosure on common/public services
• Disclosure of known public files or directories, (e.g., robots.txt)
• Clickjacking on a public page and issues only exploitable through clickjacking
• CSRF on forms that are available to anonymous users (e.g., the contact form)
• Logout Cross-Site Request Forgery (logout CSRF)
• Presence of application or web browser ‘autocomplete’ or ‘save password’ functionality
• Lack of Secure/HTTPOnly flags on non-sensitive Cookies
• Weak Captcha/Captcha Bypass
• Forgot Password page brute force and account lockout not enforced
• OPTIONS HTTP method enabled
• Reflected file downloads
• Missing Cache-control
• Directory Listing
• Missing HTTP security headers, (specifically OWASP list of useful HTTP headers)
• SSL Issues (BEAST, BREACH, Renegotiation attack, Forward secrecy not enabled, weak ciphers)
• Not performing rate limiting on non-login endpoints
• Content spoofing
• HPKP/HSTS preloading
• Generic examples of Host header attacks without evidence of the ability to target a remote victim
• Reports exploiting the behavior of, or vulnerabilities in, outdated browsers
• SPF, DKIM, or DMARC settings & Email Spoofing
• Mixed Content Scripting & Self XSS
• EXIF Geolocation data
• Open WordPress JSON API without an exploit
• Password Reset token leakage (This is known and we will implement a fix)
• Password policy

5. RECOGNITIONS AND REWARDS

Embibe is happy to thank security researchers who submit vulnerability reports and are helping us to improve our overall security posture at Embibe for our employees, customers, and guests.  Currently Embibe does not have a bounty/cash reward program for vulnerability disclosures, but we express our gratitude for your contribution in different ways. Embibe will publish the Security researcher in our Hall of Fame column under our reward program.

5.1. IN SCOPE Note:
Please run “whois” lookup before you submit any issues on domains found from Subdomain Scanners.

Target	Eligible for Recognition
To register you as a new customer on the Embibe Platform Criticality: High	Yes
Embibe.com Criticality: High	Yes
Apple AppStore : EMBIBE : Learning Outcomes App EMBIBE for Parents Criticality: High	Yes
Apple AppStore : EMBIBE : Learning Outcomes AppEMBIBE for Parents Criticality: High	Yes