Scanwise: Website Security Scanner for Small Teams

Scanwise is a website security scanner for people who build and maintain websites without a dedicated security team. It checks what is observable from outside your site, turns those observations into findings, and helps you understand what to change. The aim is practical: give a developer a useful next step instead of another unexplained score.

This blog extends that idea. We will explain common configuration problems, show how to check your own setup, and work through fixes for familiar tools and hosting platforms. If you run a small SaaS, ship client websites, or look after a business site, this is a place to build a repeatable security routine.

The gap between shipping a site and maintaining it

A website can work perfectly for customers while carrying avoidable configuration mistakes. An old deployment might leave a backup in a public directory. A move to a different CDN might change response headers. A new email provider might require DNS records that nobody added to the handoff checklist.

These are maintenance problems as much as security problems. They often sit between responsibilities: the frontend developer owns application code, someone else manages DNS, and hosting settings live in a third dashboard. A small team needs a way to bring those observations together and decide who should act.

Scanwise provides an external starting point. You supply a domain or URL you own or are authorized to assess. The service collects available signals, evaluates them, and produces a report with evidence and remediation guidance. You keep control of the decisions and the changes.

What Scanwise looks at

The scan combines several kinds of externally visible information. Coverage depends on the target and the availability of individual checks and data providers, so inspect the report's coverage information alongside its findings.

Area	Examples of questions
HTTPS and TLS	What certificate does the public endpoint present, and are there configuration issues to investigate?
HTTP headers	Which browser security policies does the website send?
DNS and email configuration	What do published records reveal about the domain and its mail authentication setup?
Public files and JavaScript	Are potentially sensitive files or credential patterns visible in public responses and assets?
Exposed infrastructure	Which observable services, subdomains, and technology signals deserve review?

A finding should connect an observation to a possible consequence and a concrete action. For example, a potentially exposed configuration file needs content evidence; a successful HTTP response alone might simply be your application's fallback page. Understanding the evidence is part of using a scanner well.

External checks, with clear boundaries

Scanwise combines passive intelligence with non-destructive HTTP, TLS, and connection checks. Some checks request information from your site, so “external” does not mean zero traffic. The service does not exploit findings or automatically rewrite your application and server configuration.

Only submit systems you own or have explicit permission to assess. For client work, agree on the hostname and scope with the client first. A publicly reachable website is not automatically yours to test.

An external report also has limits. It cannot prove that one customer cannot read another customer's invoice, that an internal service enforces permissions, or that your backups restore successfully. Those questions need application-specific tests, code review, and operational checks. Scanwise is one part of that workflow.

From a finding to a tested fix

The useful outcome of a scan is a small queue of improvements you can verify. Start with findings that involve exposed credentials, important public services, or a clear configuration failure. Read the affected hostname, evidence, severity, and confidence before applying a suggested change.

AI-assisted remediation can help translate the finding into an explanation and a proposed fix. Treat the output as something to review against your actual stack. A configuration for a self-managed Nginx server may not belong in a Vercel deployment, and a browser policy needs testing against the scripts your application uses.

Keep a short record for each change:

Finding: A response is missing the intended browser security header.
Affected page: https://app.example.com/login
Owner: Application team
Change: Add the policy in the layer that owns response headers.
Verify: Inspect the deployed response and complete the login flow.
Rollback: Restore the previous configuration if the flow breaks.

That record turns an interesting report into maintainable work. After deployment, repeat the original check and exercise the affected user journey. Save the result so the next person knows what was fixed and why.

How to run your first scan

Create an account and complete email verification when required. Eligible verified accounts receive a starter credit for the first scan, subject to anti-abuse limits. If you have just verified an email-and-password account, use the dashboard's verification refresh action so the service can recognize the updated status.

In the dashboard, submit your own domain or URL and follow the scan's progress. Once it completes, review the report and its coverage before reading the remediation guidance. A skipped or failed check is different from a completed check that found nothing.

Choose one or two concrete issues to investigate first. Trying to change every setting in a report at once makes it difficult to tell which change helped or broke something. Work through a finding, verify the result, then move to the next one.

How scan credits work

One credit covers a scan and its associated AI remediation. Additional credits are available through one-time packs; they are not a recurring subscription. The current checkout uses cryptocurrency, and purchased scan credits do not expire. Check the website's current pack details before buying.

Scheduled monitoring is available with the relevant packs and consumes a credit for each scheduled scan. It is not unlimited scanning. Choose a cadence that matches how often the site changes and check the credit balance when maintaining several client projects.

For a small site, a useful starting habit is to check after a significant deployment, hosting move, or DNS change. Recurring checks can complement that habit, but an unchanged external report does not replace reviewing changes inside the application.

What you will find on this blog

We will focus on practical topics that small teams encounter: security headers, exposed environment files, frontend API keys, SPF and DMARC, TLS, CORS, forgotten subdomains, and the limits of automated scans. Examples will use familiar stacks such as Next.js, Express, Nginx, Vercel, and Cloudflare where relevant.

Each technical guide will explain what a setting does, how to inspect your own deployment, and how to introduce a fix carefully. Expect configuration snippets, verification steps, and links to the underlying documentation. We will distinguish a confirmed observation from an assumption that needs more context.

You do not need to become a penetration tester to benefit. Start by knowing what is public, who owns each part of the setup, and how you will verify a change. The rest of the blog will help make those questions easier to answer.

Check your website — your first scan is free. Scanwise combines passive intelligence and non-destructive external checks with clear findings and AI-assisted fix suggestions. Start with a site you control, review the evidence, and turn the result into your next practical improvement.