Check out what's new! Visit the blog

Snipe-IT is Security-First

From our software to our platform, security is number one.

Security Overview

At Grokability, we don't just care about security to check boxes on a compliance form. We are passionate about security. It's part of our DNA, from the security options we provide for our users, to the rigorous security testing we do on Snipe-IT, to the core of our company culture. Like the layers of the OSI model, each layer at Grokability is important on its own, but also vital to the overall system.

Security in Our Software

In addition to providing you with configurable options for securing user accounts and access, Snipe-IT implements best-practices security for application design to prevent common attacks. Whether you host Snipe-IT yourself or you sign-up for our affordable hosting plans, you benefit from these features.

  • Two-Factor Authentication with TOTP apps (Authy, Google Authenticator, etc)
  • One-way secure password hashing with bcrypt
  • Encrypted fields secured via with AES-256 encryption via OpenSSL
  • Granular user-roles restricting access
  • Option to enforce HTTPS-only cookies
  • Cookie options for HttpOnly and encryption
  • CSRF protection using form tokens
  • Optional SSO/SAML login
  • SQL injection prevention using prepared statements
  • Input validation and output sanitization to prevent XSS
  • Option to enforce password minimum requirements
  • Option to prevent common passwords
  • Brute force prevention on login attempts
  • Middleware to enforce nosniff and SAMEORIGIN X-Frame-Options
  • Middleware to enforce a Content Security Policy (CSP)

Security in Our Process

Automated security controls are critical to any software workflow to reduce the amount of time from defect creation to defect detection. Our scans run on every code push, every time.

  • Static code analysis on every commit via Codacy, Pentest-Tools and Sensiolabs
  • Automated blocking of dependencies with known security advisories
  • Dependency vulnerability monitoring via Snyk
  • Continuous integration via Github Actions
  • In-depth code reviews
  • Regular penetration testing

Security in Our Platform

Software is only as secure as the system it runs on. We take a defense-in-depth approach to our server and network infrastructure. Customers on our hosted platform are secured through multiple layers of protection.

  • All connections secured via TLS 1.2 or higher
  • Best-practice security features such as firewalls and brute-force prevention
  • No multi-tenancy. Each customer has their own database.
  • Encrypted databases and drives
  • Customers are hosted in a data center in their own region
  • Enforced data retention policy of 3 months
  • Snapshots and individual data backups, tested regularly
  • Critical services are not accessible to the outside world
  • Code runs in tightly restricted domain environments
  • SSH access through whitelisted IPs via secure VPN only
  • IAM security profiles with two-factor authentication for our administrators
  • Detailed continuous system monitoring

Security in Our Company

We know that humans are often the weakest link in the security chain, so we proactively educate our staff to identify potential threats, from sophisticated network attacks to social engineering and phishing attempts.

  • Well-established security policy reviewed quarterly
  • Ongoing technical security training for engineers
  • Security awareness training for all employees
  • Technical and administrative controls enforcing least-privilege
  • Quarterly access-control review for Grokability admins

Recent Vulnerability Scan Results

We publish recent vulnerability scans here on our website, so that we can directly address issues and also provide additional context, since most automated scanners will generally report the same information. Any "medium" threats listed in the scan below will not be mitigated for the reasons outlined below:

Download PDF

Unable to display PDF file. Download instead.

Findings and Mitigating Factors - September 2026

  • Insecure cookie setting: missing HttpOnly flag: The application utilizes JavaScript extensively to allow the front-end GUI to communicate with the built-in API. Disallowing JavaScript from accessing those cookies would prevent the application from functioning normally, and risk is mitigated at the application layer.

  • Vulnerabilities found for server-side software: We have already manually mitigated the vulnerabilities in the libraries mentioned, or we never implemented those libraries in such a way that our users could be vulnerable. While some scanners will claim these are vulnerabilities, they are not exploitable in Snipe-IT.

  • Domain cookies are too loose: Every subdomain and their corresponding cookies are locked down to exactly that sub-domain per OWASP guidelines , so cross-contamination across domains and subdomains is not possible.

  • Server information disclosure: The web.config is an IIS configuration file. Our servers run Linux, and that file does not contain any private, database, API, or installation-specific information. It's the same generic web.config we provide in the open source product , and it simply tells IIS servers where the web root should be, which is already documented in our online documentation .

We run tests against https://grok-pen-test.snipe-it.io, which is populated with seed data and is part of the same infrastructure and runs the same code as our hosted customers and open source users.

Hosted customers are permitted to perform their own independent penetration tests, however you must limit the scan to your own hosted Snipe-IT domain (https://your-subdomain.snipe-it.io), and you must give us at least one week notice by sending an email to [email protected] with the test schedule before you begin so that we can alert our security team ahead of time, per our acceptable use policy.

Reporting a Security Vulnerability

We use Github Security Advisories to manage responsible disclosure of suspected vulnerabilities in the Snipe-IT codebase. Security vulnerabilities should be reported by creating a new GHSA or via email [email protected].

To make it easier for us to quickly triage your issue, always be sure to do the following when reporting a security issue:

  • Search the existing GHSA list. (It might have been reported already but if the fix isn't in tagged release, it might not yet have been published.)
  • Test against master or develop to be sure your issue hasn't already been patched.
  • Leave the package name and ecosystem blank. Snipe-IT is not a package.
  • Provide the version range that is affected. We'll provide the version it was fixed in if we confirm and fix the issue.
  • Provide CVSS and CWE references using the GHSA provided UI.

If we find that your security report is valid but has been reported in a previous GHSA that is currently still in draft mode (therefore currently invisible to you), we will add your Github username to the original GHSA so that you can be credited for your parallel discovery.

You can typically expect a response within five business days, and we typically have fixes out in under a week from the initial disclosure. This obviously varies based on the severity of the security issue and the difficulty in remediation, but those have historically been the timelines we work within.

Please note that we do not have a bug bounty program, and we do not offer monetary compensation for security reports, however if you end up reporting multiple high-quality vulnerabilities that lead to a fix, you might just end up on our Security Researchers Hall of Fame page!

Sign-up for a hosted account and get premium support!

Hosted accounts get secure, reliable hosting with top-notch support and preferred priority for feature requests.