Free consultation
SECURITY QUICK CHECK

Find weak spots in your public settings — and map out the risks to check next.

From a domain's public information, we quickly review basics such as HTTPS, DNS and security headers. We then use clear diagrams to organize the risks that public settings alone cannot reveal — credentials, tokens, cloud, endpoints and backups.

This check is a non-intrusive, lightweight review using public information only. It does not perform internal penetration testing, password attempts, port scanning, or detailed application vulnerability assessment.

Check a domain for free Discuss security improvements
Focuses on public information No passwords or secrets required No intrusion or brute-force attempts Results are a starting point, not a safety guarantee
Zero Trust Design

Stop trusting "inside the network" — the Zero Trust approach

This quick check shows the state of your externally visible entry points. Beyond that, Zero Trust protects you by verifying the user and device on every access — whether from the office, the cloud, or home.

  • Identity & MFA

    Enforce identity verification with Microsoft Entra. Move beyond passwords and block unauthorized logins with MFA and conditional access.

  • Device Health

    Trust only devices your company knows and manages. Check OS updates and anti-malware status, and block access from risky devices.

  • Least Privilege & Visibility

    Grant only what each person needs. Log and visualize who accessed what, so anomalies are caught quickly.

Even as generative AI and external integrations (MCP, APIs) grow, protecting by "verification" rather than a network perimeter means expansion is less likely to open new gaps.

Discuss Zero Trust design

Attackers target more than just passwords

Cookies and access tokens issued after successful sign-in, secrets held by apps and CI/CD, cloud workload identities, and the signing keys of the identity platform are all targets. So beyond the sign-in gate, you must consider — across the whole system — where credentials live and how they could be taken out.

Click the image to enlarge

Leaking into URLs and logs

If access tokens are placed in URLs, they can remain in browser history, the Referer header, proxies, APM tools and access logs.

App / API server compromise

If a server is breached, tokens and secrets may be extracted from memory, caches, databases and configuration files.

CI/CD and source control

API keys, passwords and tokens may be accidentally recorded in environment variables, build logs, configuration files and source code.

Credentials do not live in just one place. Across URLs, browsers, servers, cloud, the development pipeline and endpoints, you need a design that keeps them unseen, unretained and uncontained.

Attack paths explained by category

We have organized typical attacks into five categories. Each image can be enlarged by clicking or tapping.

Identity & sessions

Phishing and adversary-in-the-middle attacks

Fake emails and links lure users to fake sign-in pages. A relay server can sit between the user and the real service, forwarding IDs, passwords and even MFA steps to the legitimate service.

See the attack flow & countermeasures
How the attack unfolds

Once sign-in succeeds on the real service, the attacker can capture the resulting session cookie or token and reuse the already-authenticated state.

Potential impact

Even with MFA in place, some methods remain vulnerable to relay phishing, and an authenticated session can be hijacked.

Priority measures
  • Move admins and key users to passkeys / FIDO2
  • Disable legacy authentication
  • Apply Conditional Access
  • Require compliant or managed devices
  • Monitor suspicious sign-ins and sessions
  • Prepare session-revocation procedures
What Quick Check can see

Public information cannot reveal the contents of emails or sign-in pages. Only some basics, such as HTTPS and HSTS presence, can be checked.

What Quick Check cannot see

The MFA method, Conditional Access, session protection and adoption of phishing-resistant authentication cannot be checked.

Note Do not assume FIDO2 alone stops every attack. A compromised device, or session theft after sign-in, requires additional defenses.

Identity platform and signing-key compromise

An attacker breaks into the identity platform, signing keys, certificates, key-management servers or admin accounts.

See the attack flow & countermeasures
How the attack unfolds

By obtaining or misusing signing keys, they can mint JWTs and tokens that look genuinely issued, and access APIs, business apps and cloud resources.

Potential impact

Signing keys underpin the trust of authentication. If compromised, valid-looking tokens can be forged without stealing any password.

Priority measures
  • Protect high-value signing keys with HSM or Managed HSM
  • Separate control-plane and data-plane permissions
  • Separate identity, key-management and audit roles
  • Make admin rights just-in-time with PIM/JIT
  • Rotate keys regularly
  • Have emergency key-revocation, cert-renewal and token-invalidation runbooks
  • Never bring production keys into development
What Quick Check can see

Identity-platform and key-management status cannot be seen from public information.

What Quick Check cannot see

Signing-key protection (e.g. HSM), duty separation, key rotation, audit logging and emergency revocation cannot be checked.

Note HSM alone does not prevent all admin-account compromise or key misuse. Combine it with duty separation and monitoring.

Web apps & logs

XSS and malicious browser extensions

If malicious JavaScript is injected into a web app and runs, it can read localStorage, sessionStorage, on-screen input and readable cookies, and send them to an attacker.

See the attack flow & countermeasures
How the attack unfolds

A malicious extension installed by the user may also access page content, form data, cookies and tokens.

Potential impact

Authentication tokens and input from a signed-in user can be exfiltrated, leading to impersonation or data leakage.

Priority measures
  • Do not disable Razor auto-encoding
  • Avoid casual use of Html.Raw
  • Avoid innerHTML and document.write
  • Use a trusted sanitizer if HTML must be allowed
  • Configure CSP with nonce or hash
  • Set HttpOnly, Secure and appropriate SameSite on cookies
  • Do not casually store auth tokens in localStorage
  • Allow-list browser extensions on corporate devices
What Quick Check can see

The presence of Content-Security-Policy and X-Content-Type-Options headers can be checked (part of defense in depth).

What Quick Check cannot see

Whether XSS actually exists, cookie attributes (HttpOnly / Secure / SameSite), where tokens are stored, and extension management cannot be checked.

Note CSP matters, but do not make it the core of your XSS defense. The basics are input validation, context-aware output encoding and safe DOM APIs. HttpOnly cookies do not fix XSS itself.

Secrets leaking into URLs and logs

If secrets such as access_token are placed in post-login URLs, they can remain in browser history, the Referer header, reverse proxies, APM tools and web server access logs.

See the attack flow & countermeasures
How the attack unfolds

Tokens, authorization codes, session IDs and user identifiers left in logs can be viewed, forwarded and abused.

Potential impact

URLs are recorded by many systems. Even POST bodies can be captured in APM or debug logs, so 'POST is always safe' is not true.

Priority measures
  • Never put secrets in URLs
  • Mask tokens and cookies before logging
  • Review APM, proxy, WAF and access-log settings
  • Set a Referrer-Policy
  • Use short-lived tokens
  • Do not send unnecessary query strings to analytics
What Quick Check can see

URL design and log contents cannot be seen from outside. Only the presence of basic security headers can be checked.

What Quick Check cannot see

Secrets in URLs, log masking, APM and proxy configuration, and the actual Referrer-Policy value cannot be checked.

Cloud & servers

App / API server compromise

An attacker uses vulnerabilities, misconfigurations or unauthorized access to break into an app or API server and explore its internals.

See the attack flow & countermeasures
How the attack unfolds

From process memory, caches, databases, environment variables, config files, temp files and logs, they extract tokens, cookies, API keys and connection strings, then pivot to other systems.

Potential impact

Credentials the app legitimately uses become visible too, so beyond keeping intruders out, you must design so that even after a breach secrets stay hidden, privileges do not expand, and exfiltration is detected.

Priority measures
  • Do not store secrets directly in source or config files
  • Use a secret store such as Azure Key Vault
  • Reduce static credentials with Managed Identity
  • Separate app, database and management planes
  • Apply least-privilege RBAC
  • Use EDR, log monitoring and anomaly detection
  • Prepare secret-rotation procedures for a breach
What Quick Check can see

The server's internal state cannot be seen from public information. Only some externally exposed items such as HTTPS and headers can be checked.

What Quick Check cannot see

Secret management, permission design, patching, EDR and monitoring adoption, and workload isolation cannot be checked.

Cloud workload compromise and Managed Identity abuse

An attacker breaches a web app, VM, App Service or container and reaches the internal metadata service or authentication endpoint.

See the attack flow & countermeasures
How the attack unfolds

They obtain temporary access tokens, such as the workload's Managed Identity, and impersonate the app to access Azure resources.

Potential impact

Managed Identity itself is a sound mechanism, but if a workload is breached and its identity has excessive permissions, the attacker gains the same permissions.

Priority measures
  • Apply least privilege to Managed Identity too
  • Do not casually grant subscription-wide Contributor
  • Do not share one identity across unrelated workloads
  • Do not let external input drive arbitrary outbound URLs
  • Use URL allow-lists and validate resolved IPs
  • Reject private, loopback and link-local destinations
  • Re-validate redirect targets
  • Consider network isolation and Private Endpoint
What Quick Check can see

Cloud-internal permissions and network design cannot be seen from public information.

What Quick Check cannot see

Managed Identity permission design, SSRF defenses, network isolation and metadata-service protection cannot be checked.

Note Do not implement SSRF defense with simple string checks alone. Validate resolved IPs and re-check on every redirect.

Continuously assess cloud-wide vulnerabilities and attack paths

As generative AI and automation shorten the time from finding a vulnerability to launching an attack, this is the idea of continuously assessing cloud security posture with Microsoft Defender for Cloud.

See the attack flow & countermeasures
How the attack unfolds

It provides continuous assessment of assets, configuration and vulnerabilities, visibility of internet-exposed assets, attack-path analysis across identity, network and data, and multicloud management including Azure, AWS and GCP.

Potential impact

Rather than fixing everything at the same priority, you prioritize by combining exposure, permissions, vulnerabilities, data sensitivity and real attack paths.

Priority measures
  • Inventory assets and connected environments
  • Verify Defender for Cloud coverage
  • Assign owners and deadlines to recommendations
  • Prioritize high-risk items from attack paths
  • Review internet-exposed assets regularly
  • Record exceptions, exemptions and reasons for deferral
  • Share progress across management, IT and development
What Quick Check can see

This quick check reveals only some public assets, such as HTTPS and DNS.

What Quick Check cannot see

Comprehensive cloud-configuration assessment, attack-path analysis, Defender coverage and prioritization cannot be checked.

Note Product features and names may change, so please verify against the latest Microsoft Learn documentation.

Endpoints & admins

Malware on user devices

This shows how a device signed in to business apps or cloud services becomes compromised by malware.

See the attack flow & countermeasures
How the attack unfolds

From a compromised device, saved browser credentials, process memory, cookies and tokens, caches and temp files, and screen or input data can be stolen.

Potential impact

Even with strong authentication, if the device used to sign in is compromised, post-login credentials can be stolen. For critical or admin work, device health must be part of the authentication conditions.

Priority measures
  • Deploy EDR and verify no onboarding gaps
  • Apply attack-surface-reduction rules
  • Require managed/compliant devices via Conditional Access
  • Reduce local administrator rights
  • Enforce application control
  • Use dedicated admin devices (PAW / SAW)
  • Have device-isolation and token-revocation procedures
What Quick Check can see

Device state cannot be seen from public information at all.

What Quick Check cannot see

EDR deployment, device compliance, Conditional Access, local admin rights and application control cannot be checked.

Recovery & backup

Immutable backups that let you recover after a breach

Backups from Azure and on-premises are saved to a protected area, and a central Immutable Vault keeps them undeletable and tamper-proof for the retention period.

See the attack flow & countermeasures
How the attack unfolds

Even if an attacker or a compromised admin tries to delete backups or recovery points, shorten retention or disable protection, defense in depth protects these critical operations.

Potential impact

For ransomware resilience, you must protect not only production data but the backups themselves from attackers and compromised admins.

Priority measures
  • Enable immutability on supported vaults
  • Consider a Locked state once operations stabilize
  • Enable Soft Delete
  • Configure Resource Guard and Multi-user Authorization (MUA)
  • Separate backup admins from security admins
  • Place Resource Guard in a separate subscription or tenant
  • Run restore tests regularly
  • Set RPO, RTO and retention from business requirements
What Quick Check can see

Backup and recovery design cannot be seen from public information.

What Quick Check cannot see

Vault settings, immutability, Soft Delete, MUA, duty separation and restore-test status cannot be checked.

Note The image is conceptual. Not every Azure database or on-premises product is protected the same way just by enabling a setting. Available features vary by supported workload, vault type, region and method, so verify in your actual environment.

If you don't know where to start, organize it in five steps

You don't need to fix everything at once. The idea is to address, in order, what has the biggest impact and is easiest to exploit.

  1. STEP 1 Protect the entry points exposed to the internet

    • Always-on HTTPS and HTTP→HTTPS redirect
    • Manage TLS certificate expiry
    • Add basic security headers such as HSTS
    • Close unnecessary public ports and admin panels

  2. STEP 2 Strengthen authentication and accounts

    • Phishing-resistant multi-factor authentication
    • Conditional Access considering device, location and risk
    • Minimize admin rights with PIM/JIT
    • Clean up leavers and unused accounts

  3. STEP 3 Review how apps and data are handled

    • Validate input and escape output (XSS defense)
    • Keep secrets out of URLs and logs
    • Manage secrets in Key Vault or similar
    • Integrate APIs and services with least privilege

  4. STEP 4 Continuously monitor cloud and devices

    • Continuous cloud-posture assessment and exposed-asset visibility
    • EDR deployment and device compliance
    • Log aggregation and anomaly detection
    • Prepared incident-response procedures

  5. STEP 5 Be able to recover even after a breach

    • Tamper- and deletion-resistant immutable backups
    • Separate backup admins from production admins
    • Regular restore tests
    • Set RPO/RTO and retention from business requirements

This order is only a guide for organizing work. Real priorities depend on exposure, the sensitivity of the data you handle and business impact.

Turn your check results into a concrete improvement plan

This quick check is only a starting point. From here, we help organize concrete improvements tailored to your environment and operations.

Web publishing configuration review

  • Review HTTPS, TLS and security headers
  • Check redirects and cookie attributes
  • Identify unnecessary public assets
  • Specify improvements and prioritize them

Entra ID and authentication review

  • Design MFA and Conditional Access
  • Review admin rights and PIM/JIT
  • Organize guest and external-collaboration permissions
  • Define responses to sign-in risk

Azure and multicloud review

  • Approach to continuous cloud-posture assessment
  • Understand exposed assets and attack paths
  • Review permissions, network and data protection
  • A prioritized improvement roadmap

Application and development-process review

  • Design input validation and output escaping
  • Secret management and configuration handling
  • Review dependencies and the supply chain
  • Build security into the development process

Ransomware resilience and recovery design

  • Design immutable backups
  • Backup governance and duty separation
  • Restore tests and recovery runbooks
  • Set RPO/RTO and retention policy
Discuss your check results Book a 30-minute security consultation

The review scope is adjusted to your environment and scale. Start by telling us your current situation and concerns.

What this quick check can and cannot see

What this check can confirm

The items below reflect only what the current backend implementation actually checks.

  • Whether the site is served over HTTPS
  • TLS certificate expiry
  • Presence of key security headers (HSTS / CSP / X-Content-Type-Options / X-Frame-Options)
  • Redirection from HTTP to HTTPS
  • Public DNS records (A / AAAA)
  • Public mail-authentication settings (SPF / DMARC)

What this check alone cannot confirm

  • Authorization flaws inside the application
  • Actual testing for SQL injection or XSS
  • Entra ID or Conditional Access configuration
  • How cookies and tokens are stored
  • Secrets inside source code or CI/CD
  • Data in server memory or caches
  • Managed Identity permission design
  • Malware infection on user devices
  • How signing keys and certificates are managed
  • Deletion resistance of backups
  • Internal network or admin console settings

Checking public settings is only the entry point. For critical systems, you need to evaluate application, identity, cloud, endpoints and backups together.

Start by checking your public settings

Settings visible from outside a website hold important clues for preventing attacks. However, having no issues in public settings is not the same as the whole system being secure.

Enter in the form example.com No http://, https:// or path needed Use a domain you own or are authorized to check

Frequently asked questions

Does passing this quick check mean my security is fine?

No. This diagnosis checks only the public entry points of a domain (HTTPS, DNS, mail authentication and so on). It does not cover identity platforms, cloud configuration, devices, internal systems or backups. It is not a guarantee of security—treat it as a first step to notice issues.

Is the domain I enter stored?

This tool does not persistently store the domain you enter in a database or similar. It only connects to the target domain temporarily to run the diagnosis and display the result. The results-page URL does not contain the domain either.

Can I check a domain my company doesn't manage?

The tool performs an external check using publicly available information, but in principle please use it on domains you own or are authorized to test. It is not intended for excessive probing or offensive actions against others' domains.

If an item shows "no problem," is it safe going forward?

It is only an external check at that point in time. Situations change with certificate expiry, configuration changes and new vulnerabilities. Assume regular re-checks and continuous monitoring and operations.

Can I apply the diagrams and product names here directly to my company?

The diagrams are conceptual, meant to convey ideas. The features and settings actually available depend on your workload, licensing, region and configuration. Before adopting anything, please verify against the latest official documentation and in your own environment.

If I want help improving, where should I start?

Start by sharing your quick-check results from this page and your concerns. We'll help you organize where to begin—web publishing, authentication, cloud, apps or recovery—based on your situation. Feel free to reach out via the contact form or by booking a consultation.