The security scan of www.elsazon.com found 38 medium and low severity issues. No critical vulnerabilities were detected, but 10 issues should be addressed this week to harden your security posture. Detailed fix instructions are included for each finding.
Public IP 198.185.159.144 (hosted by Squarespace, Inc.) has an abuse confidence score of 29/100 from 25 report(s) in the last 90 days on AbuseIPDB.
A flagged IP usually means one of two things: this server has already been compromised and is being used to send spam or attack other systems, or this is a shared-hosting IP where a different customer on the same server is doing something malicious — either way, some mail providers and firewalls will treat traffic from this IP with extra suspicion, which can affect email deliverability and how visitors' security software treats your site.
If this is a dedicated server, check for signs of compromise (unexpected processes, outbound traffic, unfamiliar scheduled tasks) and consider a malware scan. If this is shared hosting, contact your hosting provider — ask whether the IP is shared and whether they can move you to a clean one. You can see the specific reports at https://www.abuseipdb.com/check/198.185.159.144.
Visiting http:// doesn't redirect to https:// — some visitors may use an unencrypted connection without knowing
Anyone who types or clicks an http:// link is sending their activity on your site — potentially including form data or passwords — unencrypted, where it can be read by anyone on the same public wifi or compromised network.
Example: A customer types the domain into their browser without 'https://', lands on the unencrypted version of the site, and submits a form before ever reaching the secure page — sending that data in plain text the whole time.
Add a permanent redirect from HTTP to HTTPS. Nginx: add 'return 301 https://$host$request_uri;' in your port 80 server block. Apache: add 'RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]' in your .htaccess. Cloudflare users: go to SSL/TLS > Edge Certificates > enable 'Always Use HTTPS'.
CWE-319 — Cleartext Transmission of Sensitive Information
Sensitive data is sent over the network unencrypted, so anyone monitoring the connection can read it.
Missing Strict-Transport-Security (HSTS) — browsers aren't forced to always use HTTPS, leaving visitors open to downgrade attacks
An attacker on the same network as a visitor (public wifi, a compromised router, etc.) can trick their browser into using the insecure version of your site and intercept what they type — raising the odds of stolen logins or payment details.
Example: An attacker on a shared network intercepts a visitor's first request (which defaults to HTTP) before the redirect happens, and silently serves them a fake version of the page instead of the real site.
Add the HSTS header to your web server. Nginx: add 'add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;' in your server block. Apache: add 'Header always set Strict-Transport-Security "max-age=31536000"' in your config. Cloudflare: SSL/TLS > Edge Certificates > enable HTTP Strict Transport Security.
CWE-319 — Cleartext Transmission of Sensitive Information
Sensitive data is sent over the network unencrypted, so anyone monitoring the connection can read it.
Missing X-Frame-Options — your website can be embedded in an attacker's invisible iframe to trick users into unwanted actions
An attacker could trick your customers into clicking hidden buttons — like 'change password' or 'confirm purchase' — without realizing it, potentially leading to account takeovers or unauthorized actions carried out under your brand's name.
Example: An attacker embeds the site's 'delete account' or 'confirm payment' button inside an invisible iframe on their own page, disguised under something like a fake 'play video' button — a visitor's real click triggers the hidden action on your site.
Add the X-Frame-Options header. Nginx: 'add_header X-Frame-Options "SAMEORIGIN" always;' Apache: 'Header always set X-Frame-Options SAMEORIGIN' This tells browsers to only allow your site to be framed by pages on the same domain.
CWE-1021 — Improper Restriction of Rendered UI Layers (Clickjacking)
The site doesn't prevent itself from being embedded inside another page, which attackers can exploit to trick users into clicking something they didn't intend to.
Missing Content-Security-Policy (CSP) — this site has no CSP defense-in-depth layer, so if any cross-site scripting weakness exists elsewhere it's easier to exploit; this finding on its own doesn't mean an XSS vulnerability exists on this site
CSP is a defense-in-depth browser control, not evidence of an active vulnerability by itself — but if an attacker ever manages to slip malicious script onto your site through some other weakness (e.g. a vulnerable plugin or a comment field), a good CSP is often what stops that script from running and stealing customer data such as login sessions or payment details. Without it, that second layer of protection isn't there.
Example: A vulnerable comment form or compromised ad widget lets an attacker inject a script tag; with a properly scoped CSP in place, the browser would refuse to run it — without CSP, that same injected script runs freely and can forward a visitor's session cookie to the attacker.
Add a Content-Security-Policy header, but roll it out carefully — a misconfigured CSP can break legitimate scripts/styles on the site. Start by deploying it in Report-Only mode first, which reports violations without blocking anything: 'add_header Content-Security-Policy-Report-Only "default-src \'self\'; script-src \'self\'; object-src \'none\'; report-uri /csp-report";' Review the reports for a while to catch anything the policy would break, adjust the policy, then switch the header name to 'Content-Security-Policy' (without '-Report-Only') to start enforcing it. For WordPress or complex sites, use https://csp-evaluator.withgoogle.com to help build the policy.
CWE-693 — Protection Mechanism Failure
A security safeguard that should be protecting the system is missing, disabled, or not strong enough.
The path /.env returns a restricted-access response (401/403) that is genuinely distinct from how this site handles random nonexistent paths — this confirms *something* is being specially handled at this path, but the response contains no content confirming what it actually is — this exposes credentials or sensitive configuration that should never be public
Exposed credentials in /.env (API keys, database passwords, AWS access keys) give an attacker direct access to your critical systems — databases, cloud infrastructure, third-party APIs, and internal tools. A single exposed credential can lead to total infrastructure compromise.
Example: An AWS credentials file exposed at /.env contained a key with full EC2/RDS access. An attacker used it to launch crypto miners on the account, incurring $50k in charges within 72 hours before discovery. The attacker also captured all database dumps and sold them on underground forums.
1. IMMEDIATELY rotate all exposed credentials (API keys, database passwords, SSH keys). Treat them as fully compromised. 2. Block public access to /.env via web server rules (Nginx: 'location ~ /\.env { deny all; }'). 3. Never commit secrets to version control — use .gitignore and environment variable loaders (python-dotenv, Node's dotenv). 4. Use a secrets manager (AWS Secrets Manager, HashiCorp Vault, Doppler) for production credentials.
CWE-798 — Use of Hard-coded Credentials
A username, password, or key is built directly into the code or configuration, where it can be found and reused by an attacker.
The path /.git/HEAD returns a restricted-access response (401/403) that is genuinely distinct from how this site handles random nonexistent paths — this confirms *something* is being specially handled at this path, but the response contains no content confirming what it actually is — this exposes the site's Git repository metadata, not an admin login
This is not a login page to brute-force — a publicly accessible /.git/HEAD can let an attacker reconstruct this site's Git repository: full source code, configuration files, commit history, internal file paths, and any secrets that were ever committed, even ones later removed from the latest version but never rotated.
Example: A free, widely available tool rebuilds this site's entire source code and commit history from the exposed .git folder within minutes — sometimes turning up a hardcoded API key or password that was deleted from the current code but never actually rotated.
Block public access to /.git/HEAD entirely — it should never be servable. Nginx: 'location ~ /\.git { deny all; }'. Apache: '<DirectoryMatch "\.git"> Require all denied </DirectoryMatch>'. Better yet, don't deploy the .git folder to the live server at all. If any credentials were ever committed to this repo, rotate them — treat them as compromised.
The path /wp-admin/ returns a restricted-access response (401/403) that is genuinely distinct from how this site handles random nonexistent paths — this confirms *something* is being specially handled at this path, but the response contains no content confirming what it actually is — this exposes administration functionality to anyone on the internet
Publicly reachable admin panels are a primary target for automated attacks. An attacker who can reach /wp-admin/ can attempt brute-force login, exploit known vulnerabilities in the admin software, or leverage it as a stepping stone to full server compromise — without needing any insider knowledge of the site.
Example: Automated bots constantly scan the internet for paths like /wp-admin/. A business that left a default admin URL accessible was compromised when a bot found it, brute-forced a weak password in minutes, and installed backdoor malware — all without any human attacker being involved.
Restrict access to /wp-admin/ by IP allowlist, move it to a non-standard path, or disable it if not needed. Nginx: 'location ^~ /wp-admin/ { allow YOUR_IP; deny all; }'. Also ensure strong, unique credentials are set for any admin accounts, and enable multi-factor authentication where supported.
The path /phpmyadmin/ returns a restricted-access response (401/403) that is genuinely distinct from how this site handles random nonexistent paths — this confirms *something* is being specially handled at this path, but the response contains no content confirming what it actually is — this exposes administration functionality to anyone on the internet
Publicly reachable admin panels are a primary target for automated attacks. An attacker who can reach /phpmyadmin/ can attempt brute-force login, exploit known vulnerabilities in the admin software, or leverage it as a stepping stone to full server compromise — without needing any insider knowledge of the site.
Example: Automated bots constantly scan the internet for paths like /phpmyadmin/. A business that left a default admin URL accessible was compromised when a bot found it, brute-forced a weak password in minutes, and installed backdoor malware — all without any human attacker being involved.
Restrict access to /phpmyadmin/ by IP allowlist, move it to a non-standard path, or disable it if not needed. Nginx: 'location ^~ /phpmyadmin/ { allow YOUR_IP; deny all; }'. Also ensure strong, unique credentials are set for any admin accounts, and enable multi-factor authentication where supported.
The path /admin.php returns a restricted-access response (401/403) that is genuinely distinct from how this site handles random nonexistent paths — this confirms *something* is being specially handled at this path, but the response contains no content confirming what it actually is — this exposes administration functionality to anyone on the internet
Publicly reachable admin panels are a primary target for automated attacks. An attacker who can reach /admin.php can attempt brute-force login, exploit known vulnerabilities in the admin software, or leverage it as a stepping stone to full server compromise — without needing any insider knowledge of the site.
Example: Automated bots constantly scan the internet for paths like /admin.php. A business that left a default admin URL accessible was compromised when a bot found it, brute-forced a weak password in minutes, and installed backdoor malware — all without any human attacker being involved.
Restrict access to /admin.php by IP allowlist, move it to a non-standard path, or disable it if not needed. Nginx: 'location ^~ /admin.php { allow YOUR_IP; deny all; }'. Also ensure strong, unique credentials are set for any admin accounts, and enable multi-factor authentication where supported.
Missing X-Content-Type-Options — browsers may guess file types incorrectly, which can enable content injection
This is a minor gap on its own, but it slightly raises the odds that a malicious file could be misread as something else by a visitor's browser, helping a separate attack succeed.
Example: A user-uploaded file intended to be harmless (like an image) is reinterpreted by the browser as executable script because the server never told it what the file actually was, letting an unrelated vulnerability turn into a working attack.
Add: 'add_header X-Content-Type-Options "nosniff" always;' (Nginx) or 'Header always set X-Content-Type-Options nosniff' (Apache). This is a one-line fix that takes 2 minutes.
CWE-693 — Protection Mechanism Failure
A security safeguard that should be protecting the system is missing, disabled, or not strong enough.
Missing Referrer-Policy — page URLs (which may include sensitive data) are shared with third-party sites your pages link to
If any of your page addresses contain sensitive details (like a password-reset token or account ID), that information could leak to outside sites your pages link to — a small but easily avoidable privacy gap.
Example: A customer clicks an outbound link from a page whose URL happens to include an account ID or a password-reset token, and that full address — token included — is handed to the destination site in the Referer header.
Add: 'add_header Referrer-Policy "strict-origin-when-cross-origin" always;' (Nginx) or 'Header always set Referrer-Policy strict-origin-when-cross-origin' (Apache).
CWE-16 — Configuration
The weakness comes from how the software was configured, not from a flaw in its code.
Missing Permissions-Policy — browser features like camera, microphone, and location aren't restricted for embedded third-party scripts
If you ever embed third-party ads, widgets, or analytics scripts, they could request a visitor's camera, microphone, or location without you intending to allow it — an avoidable privacy risk for your customers.
Example: An embedded ad network's script requests the visitor's location or microphone access through a permission prompt the site owner never intended to allow, simply because nothing in the page's headers restricted it.
Add: 'add_header Permissions-Policy "camera=(), microphone=(), geolocation=()" always;' Adjust based on what your site actually uses. This limits what ad/analytics scripts can access.
CWE-693 — Protection Mechanism Failure
A security safeguard that should be protecting the system is missing, disabled, or not strong enough.
The path /.aws/credentials returns a restricted-access response (401/403) that is genuinely distinct from how this site handles random nonexistent paths — this confirms *something* is being specially handled at this path, but the response contains no content confirming what it actually is — this exposes credentials or sensitive configuration that should never be public
Exposed credentials in /.aws/credentials (API keys, database passwords, AWS access keys) give an attacker direct access to your critical systems — databases, cloud infrastructure, third-party APIs, and internal tools. A single exposed credential can lead to total infrastructure compromise.
Example: An AWS credentials file exposed at /.aws/credentials contained a key with full EC2/RDS access. An attacker used it to launch crypto miners on the account, incurring $50k in charges within 72 hours before discovery. The attacker also captured all database dumps and sold them on underground forums.
1. IMMEDIATELY rotate all exposed credentials (API keys, database passwords, SSH keys). Treat them as fully compromised. 2. Block public access to /.aws/credentials via web server rules (Nginx: 'location ~ /\.env { deny all; }'). 3. Never commit secrets to version control — use .gitignore and environment variable loaders (python-dotenv, Node's dotenv). 4. Use a secrets manager (AWS Secrets Manager, HashiCorp Vault, Doppler) for production credentials.
CWE-798 — Use of Hard-coded Credentials
A username, password, or key is built directly into the code or configuration, where it can be found and reused by an attacker.
The path /.id_rsa returns a restricted-access response (401/403) that is genuinely distinct from how this site handles random nonexistent paths — this confirms *something* is being specially handled at this path, but the response contains no content confirming what it actually is — this exposes credentials or sensitive configuration that should never be public
Exposed credentials in /.id_rsa (API keys, database passwords, AWS access keys) give an attacker direct access to your critical systems — databases, cloud infrastructure, third-party APIs, and internal tools. A single exposed credential can lead to total infrastructure compromise.
Example: An AWS credentials file exposed at /.id_rsa contained a key with full EC2/RDS access. An attacker used it to launch crypto miners on the account, incurring $50k in charges within 72 hours before discovery. The attacker also captured all database dumps and sold them on underground forums.
1. IMMEDIATELY rotate all exposed credentials (API keys, database passwords, SSH keys). Treat them as fully compromised. 2. Block public access to /.id_rsa via web server rules (Nginx: 'location ~ /\.env { deny all; }'). 3. Never commit secrets to version control — use .gitignore and environment variable loaders (python-dotenv, Node's dotenv). 4. Use a secrets manager (AWS Secrets Manager, HashiCorp Vault, Doppler) for production credentials.
CWE-798 — Use of Hard-coded Credentials
A username, password, or key is built directly into the code or configuration, where it can be found and reused by an attacker.
No SPF record — there's no DNS-level list of which mail servers are authorized to send using this domain's envelope sender, so any server can pass an SPF check for your domain (note: this domain publishes no MX records, so it may not send email at all — adding SPF/DMARC here is preventative, to stop spoofing of a non-sending domain, and is low priority)
Without SPF, nothing tells receiving mail servers which senders are legitimate for this domain's SMTP envelope, making it easier for forged mail to get through — and easier for your own legitimate mail to be misjudged as spam. Note that SPF on its own, even correctly configured, doesn't stop the visible 'From:' address a recipient sees from being spoofed — that requires DMARC (see below) to enforce alignment between SPF/DKIM and the From header.
Example: A customer receives an email that looks exactly like it's from the business — same display name, same domain — asking them to 'confirm' a payment or click a link, with nothing in DNS to stop the forgery or warn the recipient.
Add an SPF TXT record to your DNS listing every service that actually sends mail for this domain — leaving one out will cause its mail to fail SPF and possibly get rejected. Log into your domain registrar, go to DNS, add a TXT record for '@' with a value matching your provider: Google Workspace: 'v=spf1 include:_spf.google.com -all' | Microsoft 365: 'v=spf1 include:spf.protection.outlook.com -all'. If you use additional senders (helpdesk, marketing platform, invoicing tool, etc.), add each as its own 'include:' entry in the same record — a domain can only have one SPF TXT record, so don't create a second one. Use https://mxtoolbox.com/spf.aspx to verify, then add a DMARC record too so the visible From address is covered as well.
CWE-290 — Authentication Bypass by Spoofing
A system trusts information that can be forged, so an attacker can impersonate a trusted party — for email, missing SPF/DMARC/DKIM lets a sender fake your domain.
No DMARC record — your domain has no DMARC email-authentication policy, which makes it easier to impersonate your business in email (note: this domain publishes no MX records, so it may not send email at all — this is preventative hardening and low priority)
This makes it significantly easier for scammers to send convincing fake emails 'from' your business — a common tactic in invoice fraud and phishing — which can directly cost your customers money and damage trust in your brand.
Example: A scammer sends an invoice-fraud email that appears to come straight from the business's own domain; with no DMARC record in place, nothing tells the recipient's mail provider the message is forged, so it lands in the inbox looking completely legitimate.
Add a DMARC TXT record to your DNS. Go to your domain registrar's DNS settings, add a TXT record for '_dmarc' (not '@') with value: 'v=DMARC1; p=none; rua=mailto:youremail@yourdomain.com' Start at p=none — this only turns on reporting, nothing is blocked yet. Review the aggregate reports for a few weeks to confirm every legitimate mail source for this domain (email provider, helpdesk, marketing tools, etc.) is passing DMARC alignment, then move to p=quarantine, and finally p=reject once you're confident nothing legitimate will be caught. Verify at https://mxtoolbox.com/dmarc.aspx
CWE-290 — Authentication Bypass by Spoofing
A system trusts information that can be forged, so an attacker can impersonate a trusted party — for email, missing SPF/DMARC/DKIM lets a sender fake your domain.
Public IP 198.185.159.144 is registered to Squarespace, Inc. — network: SQUARESPACE — block: 198.185.159.0 – 198.185.159.255.
This is informational — it tells you (and anyone else who looks it up) which hosting provider or network actually operates this IP. Useful for confirming you're hosted where you expect, or for context if the IP reputation check above flags anything.
No action required — this is identifying information, not a vulnerability.
No DKIM record found under common selector names — this does not confirm DKIM is unconfigured, only that it wasn't found under any of the selector names checked; many providers use a custom or provider-specific selector this check can't guess
If DKIM genuinely isn't configured, email providers increasingly use it as a trust signal, and its absence can make legitimate emails more likely to be flagged as suspicious or land in spam. But this check only queries a fixed list of common selector names (default, google, mail, etc.) — many providers assign a random or account-specific selector, so this finding should be treated as 'couldn't confirm DKIM,' not 'DKIM is definitely missing.'
Example: A legitimate invoice email from the business gets flagged as suspicious or dropped into spam by the recipient's mail provider, simply because there's no DKIM signature to prove the message wasn't altered or forged in transit — this only actually happens if DKIM is truly unconfigured, which this check alone can't confirm.
First confirm whether DKIM is actually configured: check your email provider's admin console (Google Workspace: Admin console > Apps > Gmail > Authenticate email; Microsoft 365: Defender > Email authentication > DKIM) for the exact selector name in use, since it's often not one of the common defaults this scan checks. If it turns out DKIM genuinely isn't enabled, turn it on there and add the resulting TXT record to DNS. If you're not sure how to check, share the selector name your provider gives you and this can be verified directly.
CWE-290 — Authentication Bypass by Spoofing
A system trusts information that can be forged, so an attacker can impersonate a trusted party — for email, missing SPF/DMARC/DKIM lets a sender fake your domain.
/.env returned HTTP 403 — access control blocked the request and nothing was accessed. Note: a 403 like this is often a generic WAF / default-deny rule rather than proof a real file exists at this path — verify manually before treating it as a real resource.
/.env returned HTTP 403 — access control blocked the request and nothing was accessed. Note: a 403 like this is often a generic WAF / default-deny rule rather than proof a real file exists at this path — verify manually before treating it as a real resource.
No action needed if this is intentionally restricted or is just a WAF default-deny. If it maps to a real protected resource, confirm the protection is deliberate and any credentials aren't left at a default.
/.git/HEAD returned HTTP 403 — access control blocked the request and nothing was accessed. Note: a 403 like this is often a generic WAF / default-deny rule rather than proof a real file exists at this path — verify manually before treating it as a real resource.
/.git/HEAD returned HTTP 403 — access control blocked the request and nothing was accessed. Note: a 403 like this is often a generic WAF / default-deny rule rather than proof a real file exists at this path — verify manually before treating it as a real resource.
No action needed if this is intentionally restricted or is just a WAF default-deny. If it maps to a real protected resource, confirm the protection is deliberate and any credentials aren't left at a default.
/.git/config returned HTTP 403 — access control blocked the request and nothing was accessed. Note: a 403 like this is often a generic WAF / default-deny rule rather than proof a real file exists at this path — verify manually before treating it as a real resource.
/.git/config returned HTTP 403 — access control blocked the request and nothing was accessed. Note: a 403 like this is often a generic WAF / default-deny rule rather than proof a real file exists at this path — verify manually before treating it as a real resource.
No action needed if this is intentionally restricted or is just a WAF default-deny. If it maps to a real protected resource, confirm the protection is deliberate and any credentials aren't left at a default.
/wp-config.php.bak returned HTTP 403 — access control blocked the request and nothing was accessed. Note: a 403 like this is often a generic WAF / default-deny rule rather than proof a real file exists at this path — verify manually before treating it as a real resource.
/wp-config.php.bak returned HTTP 403 — access control blocked the request and nothing was accessed. Note: a 403 like this is often a generic WAF / default-deny rule rather than proof a real file exists at this path — verify manually before treating it as a real resource.
No action needed if this is intentionally restricted or is just a WAF default-deny. If it maps to a real protected resource, confirm the protection is deliberate and any credentials aren't left at a default.
/.svn/entries returned HTTP 403 — access control blocked the request and nothing was accessed. Note: a 403 like this is often a generic WAF / default-deny rule rather than proof a real file exists at this path — verify manually before treating it as a real resource.
/.svn/entries returned HTTP 403 — access control blocked the request and nothing was accessed. Note: a 403 like this is often a generic WAF / default-deny rule rather than proof a real file exists at this path — verify manually before treating it as a real resource.
No action needed if this is intentionally restricted or is just a WAF default-deny. If it maps to a real protected resource, confirm the protection is deliberate and any credentials aren't left at a default.
/config.php returned HTTP 403 — access control blocked the request and nothing was accessed. Note: a 403 like this is often a generic WAF / default-deny rule rather than proof a real file exists at this path — verify manually before treating it as a real resource.
/config.php returned HTTP 403 — access control blocked the request and nothing was accessed. Note: a 403 like this is often a generic WAF / default-deny rule rather than proof a real file exists at this path — verify manually before treating it as a real resource.
No action needed if this is intentionally restricted or is just a WAF default-deny. If it maps to a real protected resource, confirm the protection is deliberate and any credentials aren't left at a default.
/.htpasswd returned HTTP 403 — access control blocked the request and nothing was accessed. Note: a 403 like this is often a generic WAF / default-deny rule rather than proof a real file exists at this path — verify manually before treating it as a real resource.
/.htpasswd returned HTTP 403 — access control blocked the request and nothing was accessed. Note: a 403 like this is often a generic WAF / default-deny rule rather than proof a real file exists at this path — verify manually before treating it as a real resource.
No action needed if this is intentionally restricted or is just a WAF default-deny. If it maps to a real protected resource, confirm the protection is deliberate and any credentials aren't left at a default.
/phpinfo.php returned HTTP 403 — access control blocked the request and nothing was accessed. Note: a 403 like this is often a generic WAF / default-deny rule rather than proof a real file exists at this path — verify manually before treating it as a real resource.
/phpinfo.php returned HTTP 403 — access control blocked the request and nothing was accessed. Note: a 403 like this is often a generic WAF / default-deny rule rather than proof a real file exists at this path — verify manually before treating it as a real resource.
No action needed if this is intentionally restricted or is just a WAF default-deny. If it maps to a real protected resource, confirm the protection is deliberate and any credentials aren't left at a default.
/.aws/credentials returned HTTP 403 — access control blocked the request and nothing was accessed. Note: a 403 like this is often a generic WAF / default-deny rule rather than proof a real file exists at this path — verify manually before treating it as a real resource.
/.aws/credentials returned HTTP 403 — access control blocked the request and nothing was accessed. Note: a 403 like this is often a generic WAF / default-deny rule rather than proof a real file exists at this path — verify manually before treating it as a real resource.
No action needed if this is intentionally restricted or is just a WAF default-deny. If it maps to a real protected resource, confirm the protection is deliberate and any credentials aren't left at a default.
/wp-admin/ returned HTTP 403 — access control blocked the request and nothing was accessed. Note: a 403 like this is often a generic WAF / default-deny rule rather than proof a real file exists at this path — verify manually before treating it as a real resource.
/wp-admin/ returned HTTP 403 — access control blocked the request and nothing was accessed. Note: a 403 like this is often a generic WAF / default-deny rule rather than proof a real file exists at this path — verify manually before treating it as a real resource.
No action needed if this is intentionally restricted or is just a WAF default-deny. If it maps to a real protected resource, confirm the protection is deliberate and any credentials aren't left at a default.
/info.php returned HTTP 403 — access control blocked the request and nothing was accessed. Note: a 403 like this is often a generic WAF / default-deny rule rather than proof a real file exists at this path — verify manually before treating it as a real resource.
/info.php returned HTTP 403 — access control blocked the request and nothing was accessed. Note: a 403 like this is often a generic WAF / default-deny rule rather than proof a real file exists at this path — verify manually before treating it as a real resource.
No action needed if this is intentionally restricted or is just a WAF default-deny. If it maps to a real protected resource, confirm the protection is deliberate and any credentials aren't left at a default.
/phpmyadmin/ returned HTTP 403 — access control blocked the request and nothing was accessed. Note: a 403 like this is often a generic WAF / default-deny rule rather than proof a real file exists at this path — verify manually before treating it as a real resource.
/phpmyadmin/ returned HTTP 403 — access control blocked the request and nothing was accessed. Note: a 403 like this is often a generic WAF / default-deny rule rather than proof a real file exists at this path — verify manually before treating it as a real resource.
No action needed if this is intentionally restricted or is just a WAF default-deny. If it maps to a real protected resource, confirm the protection is deliberate and any credentials aren't left at a default.
/.DS_Store returned HTTP 403 — access control blocked the request and nothing was accessed. Note: a 403 like this is often a generic WAF / default-deny rule rather than proof a real file exists at this path — verify manually before treating it as a real resource.
/.DS_Store returned HTTP 403 — access control blocked the request and nothing was accessed. Note: a 403 like this is often a generic WAF / default-deny rule rather than proof a real file exists at this path — verify manually before treating it as a real resource.
No action needed if this is intentionally restricted or is just a WAF default-deny. If it maps to a real protected resource, confirm the protection is deliberate and any credentials aren't left at a default.
/.vscode/settings.json returned HTTP 403 — access control blocked the request and nothing was accessed. Note: a 403 like this is often a generic WAF / default-deny rule rather than proof a real file exists at this path — verify manually before treating it as a real resource.
/.vscode/settings.json returned HTTP 403 — access control blocked the request and nothing was accessed. Note: a 403 like this is often a generic WAF / default-deny rule rather than proof a real file exists at this path — verify manually before treating it as a real resource.
No action needed if this is intentionally restricted or is just a WAF default-deny. If it maps to a real protected resource, confirm the protection is deliberate and any credentials aren't left at a default.
/.idea/workspace.xml returned HTTP 403 — access control blocked the request and nothing was accessed. Note: a 403 like this is often a generic WAF / default-deny rule rather than proof a real file exists at this path — verify manually before treating it as a real resource.
/.idea/workspace.xml returned HTTP 403 — access control blocked the request and nothing was accessed. Note: a 403 like this is often a generic WAF / default-deny rule rather than proof a real file exists at this path — verify manually before treating it as a real resource.
No action needed if this is intentionally restricted or is just a WAF default-deny. If it maps to a real protected resource, confirm the protection is deliberate and any credentials aren't left at a default.
/robots.txt is present and was used to seed additional path checks.
/robots.txt is present and was used to seed additional path checks.
No action needed — robots.txt is meant to be public.
/sitemap.xml is present and was used to seed additional path checks.
/sitemap.xml is present and was used to seed additional path checks.
No action needed — sitemap.xml is meant to be public.
/search returned HTTP 200, a real distinct response rather than the site's soft-404 page. This path isn't one a typical visitor would stumble onto by browsing the site normally, which is why it's worth a quick manual look — but its existence alone isn't a vulnerability.
/search returned HTTP 200, a real distinct response rather than the site's soft-404 page. This path isn't one a typical visitor would stumble onto by browsing the site normally, which is why it's worth a quick manual look — but its existence alone isn't a vulnerability.
Open the path yourself and confirm it's meant to be public. If it's leftover debug/test/admin tooling that should have been removed, take it down or restrict it by IP allowlist. If it's intentional, no action needed.
/account/ returned HTTP 200, a real distinct response rather than the site's soft-404 page. This path isn't one a typical visitor would stumble onto by browsing the site normally, which is why it's worth a quick manual look — but its existence alone isn't a vulnerability.
/account/ returned HTTP 200, a real distinct response rather than the site's soft-404 page. This path isn't one a typical visitor would stumble onto by browsing the site normally, which is why it's worth a quick manual look — but its existence alone isn't a vulnerability.
Open the path yourself and confirm it's meant to be public. If it's leftover debug/test/admin tooling that should have been removed, take it down or restrict it by IP allowlist. If it's intentional, no action needed.
No high-risk open ports were detected from the internet — your firewall appears to be blocking dangerous services.