Privacy Policy

Last updated: 9 June 2026

Summary

IntSecure is a self-hosted defensive website inspection tool. It runs on your server, stores its data in a local SQLite database on the same server, and does not transmit any information to the developer, a vendor, an analytics provider, or any third party. There is no "phone home", no telemetry, and no remote logging. The operator of the installation is the sole controller of every piece of data the tool produces.

1. Who this policy applies to

This policy describes how the IntSecure application handles data when installed and run by you on infrastructure you control. If you are an end-user accessing an IntSecure dashboard hosted by another party, that party — not the IntSecure project — is responsible for how your data is handled, and you should request their privacy policy directly.

2. Data the application collects and stores

The local SQLite database (intsecure.db) stores only the following:

  • Account credentials — email address and a hashed (never plaintext) password for each user who registers via ASP.NET Core Identity. Used solely to authenticate access to the dashboard.
  • Registered domains — domain names and metadata you add manually (hosting type, CMS hint, notes). These are the inspection targets you have explicitly chosen.
  • Scan runs — timestamp, status, duration, score, and which user triggered the run.
  • Scan checks — one pass/fail record per individual check executed against a target domain (e.g. "HSTS header present", "robots.txt reachable").
  • Scan findings — issues detected, severity, the URL that was checked, the HTTP status code returned, the plain-English description, and the recommended fix. For sensitive-file checks, only the URL, status code, content type, and content length are stored — response bodies are never stored.
  • Authentication session cookie — issued by ASP.NET Core Identity to keep you signed in. Necessary for the dashboard to function.

3. Data the application does not collect

  • No analytics, tracking pixels, or behavioural metrics.
  • No usage telemetry sent to the developer or any third party.
  • No crash reports sent off the server.
  • No IP address logging beyond what your web server / IIS already records.
  • No marketing, advertising, or profiling cookies.
  • No social-media integrations or external SDKs.
  • No response bodies from sensitive-file probes.
  • No credentials, secrets, or content scraped from the target domains beyond the publicly returned headers and a capped portion of the homepage HTML used to detect CMS fingerprints and SEO health.

4. Outbound network requests

The application makes HTTP(S) requests only to the domains you register, and only to perform the defensive checks documented in the project README. Requests are identified by a fixed User-Agent of IntSecureBot/1.0 so the traffic is distinguishable in your target site's logs.

Safeguards applied to every outbound request:

  • HEAD method preferred; GET only when HEAD is rejected (HTTP 405 / 501).
  • Response bodies capped at 256 KB.
  • Hard timeout (default 10 seconds).
  • Maximum redirect chain depth enforced.
  • One concurrent scan per domain — overlapping requests are skipped.
  • Approximately twenty requests per scan as an upper bound — no aggressive crawling.

No payloads associated with brute-forcing, exploit attempts, SQL injection, denial of service, or active vulnerability probing are ever generated. These behaviours are out of scope of the tool and disallowed by its design.

5. Third parties

The application has no third-party dependencies that receive data at runtime. Specifically:

  • No remote API calls to the developer or any vendor.
  • No content delivery networks fetch resources from a remote host at request time, with the limited exception of optional Google Fonts loaded by the dashboard <head>. If you wish to eliminate this, self-host the font files and remove the link tag in _Layout.cshtml.
  • No third-party authentication providers.

6. Retention

All data lives in the SQLite database file on your server for as long as you retain it. The application does not automatically delete scan runs, findings, or accounts. To delete data:

  • Individual scans can be removed from Security → Scans → Details.
  • Domains can be archived or deleted from Security → Domains.
  • User accounts can be removed via the ASP.NET Core Identity management pages.
  • The complete dataset can be purged by stopping the application and deleting intsecure.db.

7. Security of stored data

Database security is the responsibility of the server operator. Recommended practices:

  • Bind the dashboard to localhost and access it only via RDP or VPN. The default setup.ps1 deployment uses a localhost-only IIS binding.
  • Run the IIS app pool under a dedicated ApplicationPoolIdentity — never LocalSystem or an administrator account.
  • Keep the host operating system, .NET runtime, and IIS patched.
  • Back up the SQLite database file regularly if scan history matters to you.

8. Lawful basis for scanning

You may only register and scan domains that you own, host, or have explicit written permission to inspect. Scanning third-party domains without authorisation may breach computer misuse legislation in your jurisdiction. The application identifies itself in its User-Agent precisely so that any unintended request can be attributed and stopped.

9. Children

IntSecure is a system-administration tool intended for technical professionals. It is not directed at, and does not knowingly collect data from, anyone under the age of sixteen.

10. Changes to this policy

Material changes to the application's data handling will be reflected in this page and the date at the top will be updated. The current canonical version is the one bundled with the source release you are running.

11. Contact

Questions about this policy or about a specific installation should be directed to the operator of that installation. Issues with the IntSecure project itself can be raised at github.com/Selmorand/int-secure.