Includable takes the upmost responsiblity in keeping the Includable Platform and any data stored by users secure. This page lists the security standards and technologies we use to do this.
Includable and Scholica are FERPA (Family Educational Rights and Privacy Act) compliant so your student data is absolutely secure and will never be used to target advertisements without your explicit consent.
HTTPS (SSL) everywhere
All Includable web URLs that require user authentication or otherwise contain personal information are only available through an secure HTTPS connection. This is true for the main Includable and Scholica domains
scholica.courses, as well as any custom domains set up by Includable customers. Custom domains use Letsencrypt to automate the HTTPS certificate generation process.
- A SSL report for includable.com can be viewed on ssllabs.com.
- Includable servers have been patched for the Heartbleed and POODLE vulnabilities.
- Includable supports the TLS 1.0, 1.1 and 1.2 protocols, and does not support the deprecated protocols SSLv2 and SSLv3.
- Strict Transport Security (HSTS) is enabled for any application subdomain.
- Authentication cookies are saved with SecureOnly and HTTPOnly flags.
Includable database servers are located within the European Entrepreneurial Region (EER). Specifically, our application and database servers are located in data centres in Dublin, Ireland. File storage and our content delivery network uses a series of edge servers in Europe, Asia and the United States.
Infrastructure services are provided by Amazon Web Services (AWS) and DigitalOcean.
Data back ups
Includable utilizes Amazon's automatic backups of file and database storage and creates monthly offsite static back ups.
Includable enforces a password policy that requires all user-created passwords to be at least 6 characters long by default. Administrators of Includable Platform accounts are able to add more policy features.
Includable has ISO 29147 & 30111 compliant vulnerability disclosure workflows in place, as well as a bug bounty program. Vulnerabilities can be disclosed through email@example.com.
We utilize the Common Vulnerability Scoring System (CVSS) for determining the Severity of an individual vulnerability.
Verifiable proof the vulnerability exists (screenshot/video/script) is required to receive an award.
For more technically elaborate vulnerabilities, reproduction steps are required. If our security team cannot reproduce and verify an issue, a bounty cannot be awarded.
- Let us know as soon as possible upon discovery of a potential security issue, and we'll make every effort to quickly resolve the issue.
- Provide us a reasonable amount of time to resolve the issue before any disclosure to the public or a third-party.
- Make a good faith effort to avoid privacy violations, destruction of data, and interruption or degradation of our service. Only interact with accounts you own or with explicit permission of the account holder.
A good bug report should include the following information at a minimum:
- List the URL and any affected parameters
- Describe the browser, OS, and/or app version
- Describe the perceived impact. How could the bug potentially be exploited?
Findings not eligible for bounty:
- Vulnerabilities affecting outdated browsers or platforms
- Recently disclosed 0-day vulnerabilities
- "Self" XSS
- Open redirects
- Missing cookie flags
- SSL/TLS best practices
- Information disclosures
- Mixed content warnings
- Denial of Service attacks
- "HTTP Host Header" XSS
- Clickjacking/UI redressing
- Missing crumb parameters
- Software version disclosure
- Account/e-mail enumeration
- Reflected file download attacks
- Incomplete or missing SPF/DKIM
- Physical or social engineering attacks
- Results of automated tools or scanners
- Login/logout/unauthenticated/low-impact CSRF
- Presence of autocomplete attribute on web forms
- Using unreported vulnerabilities to find other bugs
- Self-exploitation (i.e. password reset links or cookie reuse)
- Issues related to networking protocols or industry standards
- Use of a known-vulnerable library (without proof of exploitability)
- Descriptive/verbose/unique error pages (without proof of exploitability)
- Missing security-related HTTP headers which do not lead directly to a vulnerability
Eligibility and Coordinated Disclosure
You will be eligible for a bounty only if you are the first person to disclose an unknown issue to Includable. The Includable development team has 30 days to respond to the report, and up to 90 days to implement a fix based on the severity of the report. Please allow for this process to fully complete before you publicly disclose the vulnerability. Note that posting details or conversations about this report before it has been approved for disclosure or posting details that reflect badly on this program and the Includable brand will result in forfeiture of any award and/or immediate removal from the program.