Level All aims to offer personalized, comprehensive support to every high school and postsecondary student in the U.S. to help them achieve their lifelong aspirations.

Report Requirements

In order to help us triage and prioritize submissions, we ask that you:

• Describe the location the vulnerability was discovered and the potential impact of exploitation.
• Provide technical information, including URL(s) affected by the bug, a detailed description of the steps needed to reproduce the vulnerability (proof of concept (PoC) scripts or screenshots are helpful), any specific tools or software used in the discovery of the bug, attachments (e.g., screenshots, logs, or code snippets), whether you identified any potential attack scenarios that could exploit this bug and, if so, a description, and any technical HTTP/application requests outputs (e.g., Burp, Caido, Wireshark, Postman).
• Provide bug details, including a name or brief description of the discovered bug, category of the bug (e.g., Cross-Site Scripting, SQL Injection, etc.), severity level of the bug (Critical, High, Medium, Low), and date and time of bug discovery.
• Provide an impact assessment, including potential consequences if the bug is exploited (e.g., data loss, unauthorized access, etc.), mitigation and remediation, proposed mitigation measures or solutions for the discovered bug, whether you attempted to contact the vendor or affected parties prior to submitting this report and, if so, details of such communication, and any additional comments or information that you think might be helpful in evaluating your submission.
• Provide your report in English, if possible.
• Do not share information about your findings with third parties or publicly disclose until we confirm that they have been remediated and we have provided prior written approval.

Rules of Engagement

• Notify us as soon as possible after you discover a real or potential security issue.
• Do not access, view, or download any personal information.
• Do not violate any applicable laws, which may include but are not limited to applicable privacy laws.
• Do not degrade the user experience, disrupt production systems, or destroy or manipulate any data.
• Perform the minimum amount of testing necessary to identify and validate the finding.
  • Do not perform additional testing after you have confirmed that a vulnerability exists.
  • Do not attempt to conduct post-exploitation, including but not limited to modification or destruction of data, interruption or degradation of Level All’s services, or pivoting with access not normally granted.
  • Do not use an exploit to compromise or exfiltrate data, establish persistent access, or pivot to other systems.
  • If you discover a vulnerability that could allow you to bypass an authentication control and gain access to another account, immediately report the vulnerability and do not take further action with the other account or its data.
• If a vulnerability or your testing causes a readily visible issue that could alert the public to the vulnerability or your testing, stop further testing and immediately report the issue to Level All, even if your report is incomplete.
• Use only your own accounts while testing. Do not compromise or test Level All’s accounts that are not your own.
• Once you have demonstrated and reported a vulnerability, do not attempt to reproduce the finding again except to the extent requested in writing by Level All.
• Provide Level All a reasonable amount of time to resolve the issue, and do not disclose publicly or to a third party without obtaining prior written approval from Level All.
• Do not submit a high volume of low-quality reports.
• Do not use third-party sites when testing; only utilize infrastructure that you expressly own and control yourself.
• Comply with all provisions of this Policy at all times.
• Test only in-scope assets, systems, services and products. Do not test out-of-scope assets, systems, services and products, and do not test with disallowed methods.
• Employees of Level All will report potential security vulnerabilities through Level All internal processes and in accordance with Level All applicable policies and procedures.
• Reports, which may include but are not be limited to the following, will generally be considered informational:
  • Open redirects without proven impact (e.g., no token leakage, no authorization bypass, no SSRF, no phishing scenario tied to an authenticated workflow).
  • Clickjacking on non‑sensitive pages (i.e., pages with no sensitive data or privileged actions).
  • Unauthenticated, logout, or login CSRF that does not change sensitive state or bypass protection.
  • Insecure Direct Object Reference (IDOR) without impact (e.g., disclosing non‑sensitive numeric IDs alone). Note: User ID exposure by itself is typically low; if you can chain it into account takeover or sensitive data access, submit as a single chained report with a working PoC.
  • Low‑impact session management findings that do not lead to account compromise or privilege escalation.
  • Role‑Based Access Control (RBAC) “multi‑role” duplicates - submit one representative example per endpoint lacking enforcement; duplicates across roles are considered the same issue.
  • Race conditions with no proven impact (e.g., no double‑spend, no privilege change, no unauthorized actions).
  • Absence of certificate pinning, code obfuscation, or jailbreak/root detection by itself
• The following forms of testing are not allowed:
  • Do not engage in disruptive testing, including but not limited to Denial of service (DoS or DDoS) tests, or any other actions or tests that could impair access to or damage a system or data or impact confidentiality, integrity or availability of information and systems.
  • Limited usage of automated scanners/tools is allowed, but automated scanners/tools will be configured to not send more than 5 requests per second to any particular service.
  • Physical testing (e.g. office access, open doors, tailgating), social engineering (e.g. phishing, vishing), or any other non-technical vulnerability testing.
• Technical items, which may include but are not limited to the following, are considered out-of-scope and not valid reports:
  • Submissions purely detected by artificial intelligence tools or models with no manual verification are out of scope.
  • Automated scanner output (raw or unvalidated) and bulk scanning are out of scope. Level All requires manually validated findings with a clear, reproducible impact and PoC.
• Additional reports that will be rejected due to out-of-scope may include but are not limited to:
  • Missing or weak security headers (generic) without exploitability (e.g., generic CSP, X‑Frame‑Options, HSTS recommendations absent a working exploit).
  • Cookies missing HttpOnly/Secure for non‑sensitive cookies only.
  • Content spoofing or text injection without the ability to modify HTML/CSS or cause a security impact (e.g., self‑XSS, self‑HTML injection, non‑persistent UI text changes).
  • Cache‑control issues on non‑sensitive pages.
  • Presence of browser autocomplete on form fields (without security impact).
  • OPTIONS / TRACE HTTP methods enabled without an exploit path.
  • Social‑engineering‑dependent attacks against employees or vendors.
  • SSL/TLS “best practice” gaps without a working exploit (e.g., ciphers/hardening recommendations).
  • Attacks requiring Man‑in‑the‑Middle (MitM), device compromise, or physical access to a user’s device.
  • Any activity that could disrupt service (e.g., DoS, DDoS, resource‑exhaustion tests).
  • Use of outdated or known‑vulnerable software/libraries without a working PoC or demonstrated impact.
  • Email authentication configuration (DMARC, DKIM, SPF) issues without demonstrated abuse leading to security impact.
  • Cache poisoning without impact; CPDoS (Cache‑Poisoned DoS) is out of scope.