SECTION 4b · DOMAIN INTELLIGENCE
Registration, DNS posture, email-authentication and network-surface intelligence gathered via standard remote lookups (WHOIS, DNS, TCP connect probe). External-safe — no intrusive scanning.
WHOIS: whois lookup failed or rate-limited.
DNS & email authentication
| A records | 172.67.132.164, 104.21.13.85 |
| MX records | — |
| NS records | — |
| SPF | No |
| DMARC | No |
| DKIM (selector hint) | No |
DNSBL reputation: IP 104.21.13.85 — listed on 1/3 (zen.spamhaus.org).
Open-port surface (3/14 common web ports reachable)
| Port | Service | Risk | Note |
|---|
| 80 | HTTP | INFO | Plain HTTP open (expected if it redirects to HTTPS). |
| 443 | HTTPS | INFO | HTTPS open (expected). |
| 8080 | HTTP-alt | MEDIUM | Port 8080 open to the internet — often exposes an admin panel or internal app server. Should not be publicly reachable. |
TLS handshake: TLSv1.3 · cipher TLS_AES_256_GCM_SHA384 · 256-bit key.
SECTION 5 · SEVERITY-PRIORITIZED REMEDIATION PLAN
Fixing the top 3 issue(s) resolves the highest-severity exposure detected. Items are ordered Critical → Info.
1
Resolved IP listed on 1 blocklist(s)
High7.0–8.9 · A08 Software & Data Integrity Failures · CWE-506DetectedResearched · citedWhere / evidence: IP 104.21.13.85 listed on: zen.spamhaus.org.
Impact: A blocklisted IP harms email deliverability and may indicate prior abuse/compromise.
Why it matters: An IP listed on Spamhaus ZEN matters because ZEN is a combined DNSBL used for email filtering, so listed sending IPs can be rejected or degraded by receivers until the underlying abuse condition is fixed and the listing is cleared[1][2]. For this finding, the authoritative remediation is to identify the specific Spamhaus zone and follow Spamhaus’s own resolution steps, then request removal after correcting the root cause[1][2][4].
1. Confirm the exact Spamhaus listing and scope using Spamhaus’s IP and Domain Reputation Checker or the IP removal flow, because ZEN is a combined list and the res
AI Recommended Fix:- An IP listed on Spamhaus ZEN matters because ZEN is a combined DNSBL used for email filtering, so listed sending IPs can be rejected or degraded by receivers until the underlying abuse condition is fixed and the listing is cleared[1][2]. For this finding, the authoritative remediation is to identify the specific Spamhaus zone and follow Spamhaus’s own resolution steps, then request removal after correcting the root cause[1][2][4].
1. Confirm the exact Spamhaus listing and scope using Spamhaus’s IP and Domain Reputation Checker or the IP removal flow, because ZEN is a combined list and the resolution depends on the specific sub-list and reason[1][2].
2. Stop any mail or traffic that is causing the listing before requesting removal; Spamhaus explicitly directs you to fix the issue found in the checker and, for IP-based listings, to use the suggested resolution steps[1][4].
3. Fix the mail-server identity and routing settings Spamhaus requires: the HELO domain must resolve to the sending IP, the sending IP must have valid reverse DNS, the reverse DNS must match the HELO domain, and forward-confirmed reverse DNS must resolve back to the sending IP[4].
4. If the IP is shared or controlled by your hosting/provider, open an abuse/remediation ticket with that provider and ask them to correct the listing condition and submit delisting if needed; Spamhaus states that some listings require the ISP/provider to act[9].
5. After the root cause is corrected, use Spamhaus’s removal
2
Content-Security-Policy header not set
Medium4.0–6.9 · A05 Security Misconfiguration · CWE-1021DetectedConfirmed fixWhere / evidence: HEAD response for the target omitted the Content-Security-Policy response header.
Impact: No CSP means injected scripts (XSS) run without a defence-in-depth backstop.
Why it matters: CSP is a key defence-in-depth control against XSS and data injection; without it, injected scripts run freely.
AI Recommended Fix:- Start with a report-only policy to measure impact, then enforce.
- Define explicit default-src / script-src allow-lists; avoid 'unsafe-inline'.
- Use nonces or hashes for any required inline scripts.
# nginx
add_header Content-Security-Policy "default-src 'self'; object-src 'none'; base-uri 'self'" always;
Involved 3
HTTP-alt port 8080 is internet-reachable
Medium4.0–6.9 · A05 Security Misconfiguration · CWE-668DetectedResearched · citedWhere / evidence: TCP connect to public IP 172.67.132.164:8080 succeeded from an external vantage — HTTP-alt reachable from the internet.
Impact: Port 8080 open to the internet — often exposes an admin panel or internal app server. Should not be publicly reachable.
Why it matters: An internet-reachable HTTP-alt port 8080 violates the **principle of least privilege** and exposes your system to unauthorized access, exploitation of unpatched development services, and malware distribution, as this port is commonly used for HTTP proxies and development servers that often lack security controls[1][2].
### 1. Why it Matters
* **Unauthorized Access & Data Theft:** An open port provides a direct entry point for attackers to bypass firewalls, potentially leading to unauthorized access to sensitive information or system compromise[1][3].
* **Exploitation of Vulnerable Service
AI Recommended Fix:- An internet-reachable HTTP-alt port 8080 violates the **principle of least privilege** and exposes your system to unauthorized access, exploitation of unpatched development services, and malware distribution, as this port is commonly used for HTTP proxies and development servers that often lack security controls[1][2].
### 1. Why it Matters
* **Unauthorized Access & Data Theft:** An open port provides a direct entry point for attackers to bypass firewalls, potentially leading to unauthorized access to sensitive information or system compromise[1][3].
* **Exploitation of Vulnerable Services:** Port 8080 is frequently used for **development, staging, or proxy servers** that often lack security patches, strong authentication, or web application firewalls (WAF), making them easy targets for SQL injection, XSS, and other attacks[1][2].
* **Malware & DDoS Launchpad:** If left unrestricted, attackers can exploit vulnerabilities to install malware, perform Distributed Denial of Service (DDoS) attacks, or use the server as a proxy to spread malware[1].
* **Service Discovery:** Open ports allow vulnerability scanners to identify HTTP services on non-standard ports, enabling attackers to perform reconnaissance and dictionary-style guessing to find hidden applications[6].
### 2. Numbered Fix Steps
1. **Restrict Inbound Access via Firewall:** Configure your firewall (e.g., `iptables`, `ufw`, AWS Security Groups, or cloud firewall rules) to **block all inbound TCP traffic to por
4
X-Frame-Options header not set
Medium4.0–6.9 · A05 Security Misconfiguration · CWE-1021DetectedConfirmed fixWhere / evidence: HEAD response for the target omitted the X-Frame-Options response header.
Impact: The page can be framed by a malicious site for clickjacking.
Why it matters: The page can be framed by a malicious site to trick users into clicks (clickjacking).
AI Recommended Fix:- Add Content-Security-Policy: frame-ancestors 'self' (preferred, modern).
- Optionally add X-Frame-Options: SAMEORIGIN for legacy browsers.
# nginx
add_header Content-Security-Policy "frame-ancestors 'self'" always;
add_header X-Frame-Options "SAMEORIGIN" always;
Quick 5
dns_no_dmarc
Low0.1–3.9 · A05 Security Misconfiguration · CWE-200DetectedConfirmed fixWhere / evidence: No DMARC record found for _dmarc.flipbook.clovitek.com — domain spoofing is unmitigated
Impact: Publicly reachable resource that should not be exposed.
Why it matters: Missing DMARC enables spoofed phishing emails, undermining user trust and enabling impersonation of your brand.
AI Recommended Fix:- Publish a _dmarc TXT record starting with p=none to begin monitoring.
- Analyse reports (rua/ruf) to identify all legitimate mail senders.
- Graduate to p=quarantine then p=reject once all legitimate sources are aligned.
# dns
_dmarc.example.com TXT "v=DMARC1; p=quarantine; rua=mailto:[email protected]"
Moderate 6
dns_no_dnssec
Low0.1–3.9 · A05 Security Misconfiguration · CWE-200DetectedConfirmed fixWhere / evidence: No DNSSEC DS record found for flipbook.clovitek.com — DNS responses may be tampered with
Impact: Publicly reachable resource that should not be exposed.
Why it matters: Without DNSSEC, DNS responses can be forged (cache poisoning, MITM), redirecting users to attacker-controlled servers.
AI Recommended Fix:- Enable DNSSEC signing at your DNS registrar or authoritative DNS provider.
- Publish DS records at the parent zone (registrar control panel).
- Verify with: dig +dnssec DS yourdomain.com @8.8.8.8
# generic
# Enable DNSSEC in your DNS provider's control panel, then add DS record at registrar.
Involved 7
http_delete_enabled
Low0.1–3.9 · A05 Security Misconfiguration · CWE-200DetectedResearched · citedWhere / evidence: DELETE request to an arbitrary path returned HTTP 301 instead of 403/404/405 — server may allow unauthenticated resource deletion.
Impact: Publicly reachable resource that should not be exposed.
Why it matters: The finding matters because an enabled **HTTP DELETE** method can allow a client to remove server resources, which can cause **data loss**, **service disruption**, or unauthorized modification if the server does not correctly enforce authentication and authorization for that method.[11][14][20] Your scan result is consistent with the broader class of “insecure HTTP method” issues, where dangerous methods such as DELETE should be disabled unless the application explicitly requires them and protects them with access control.[11][18]
1. **Confirm whether DELETE is required** for any legitimate A
AI Recommended Fix:- The finding matters because an enabled **HTTP DELETE** method can allow a client to remove server resources, which can cause **data loss**, **service disruption**, or unauthorized modification if the server does not correctly enforce authentication and authorization for that method.[11][14][20] Your scan result is consistent with the broader class of “insecure HTTP method” issues, where dangerous methods such as DELETE should be disabled unless the application explicitly requires them and protects them with access control.[11][18]
1. **Confirm whether DELETE is required** for any legitimate API or WebDAV use case; if it is not required, disable it at the web server or reverse proxy layer so requests receive **405 Method Not Allowed** or are blocked before reaching the application.[11][18]
2. **Enforce authentication and authorization** for every DELETE endpoint that must remain enabled, and verify that permission checks happen server-side for the specific resource being deleted.[18][20]
3. **Deny DELETE on static-content paths** and any directory that should never allow mutation or deletion, because unrestricted DELETE on exposed content can lead to direct file removal and denial of service.[14][20]
4. **Disable related dangerous methods** you do not need, especially **PUT**, **TRACE**, and **CONNECT**, because insecure HTTP method exposure is commonly treated as a broader hardening issue.[11][18]
5. **Verify the fix** by retesting the same arbitrary-path DELETE probe and co
8
http_put_enabled
Low0.1–3.9 · A05 Security Misconfiguration · CWE-200DetectedResearched · citedWhere / evidence: PUT request to an arbitrary path returned HTTP 301 instead of 403/404/405 — server may allow unauthenticated file writes.
Impact: Publicly reachable resource that should not be exposed.
Why it matters: **Why it matters:** An HTTP **PUT** endpoint that returns `200` for an arbitrary path can let an attacker upload or replace content on the server, which may lead to malicious file placement, site defacement, data loss, or even remote code execution if executable content is written into a web-accessible location.[2][14] OWASP’s Web Security Testing Guide notes that using `PUT` may allow arbitrary potentially malicious content to be placed on the system, leading to remote code execution, defacing, or denial of service.[14]
1. **Disable HTTP `PUT` globally** unless the application has a document
AI Recommended Fix:- **Why it matters:** An HTTP **PUT** endpoint that returns `200` for an arbitrary path can let an attacker upload or replace content on the server, which may lead to malicious file placement, site defacement, data loss, or even remote code execution if executable content is written into a web-accessible location.[2][14] OWASP’s Web Security Testing Guide notes that using `PUT` may allow arbitrary potentially malicious content to be placed on the system, leading to remote code execution, defacing, or denial of service.[14]
1. **Disable HTTP `PUT` globally** unless the application has a documented, authenticated business need for it.[1][2][4]
2. **If `PUT` is required, restrict it to authenticated and authorized users only** and block it from static-content or web-root directories where uploaded files could be executed or served directly.[1][3][5]
3. **Allow only the HTTP methods the application actually uses** (for many apps this is `GET`, `POST`, `HEAD`, and `OPTIONS`), and explicitly deny the rest at the web server or reverse proxy.[3][4]
4. **If WebDAV is enabled, disable it unless required**, because WebDAV is a common source of exposed `PUT` functionality.[3]
5. **Retest with an unauthenticated `PUT` to a random path** and confirm the server now returns `403`, `404`, or `405` instead of `200`.[14]
```apache
# Apache HTTP Server: block PUT at the server or vhost level
<LimitExcept GET POST HEAD OPTIONS>
Require all denied
</LimitExcept>
# If WebDAV is not needed, kee
9
No DMARC policy published
Low0.1–3.9 · A07 Identification & Authentication Failures · CWE-290DetectedConfirmed fixWhere / evidence: No v=DMARC1 TXT record found at _dmarc.flipbook.clovitek.com.
Impact: Without DMARC, attackers can spoof this domain in phishing with no enforcement.
Why it matters: Missing DMARC enables spoofed phishing emails, undermining user trust and enabling impersonation of your brand.
AI Recommended Fix:- Publish a _dmarc TXT record starting with p=none to begin monitoring.
- Analyse reports (rua/ruf) to identify all legitimate mail senders.
- Graduate to p=quarantine then p=reject once all legitimate sources are aligned.
# dns
_dmarc.example.com TXT "v=DMARC1; p=quarantine; rua=mailto:[email protected]"
Moderate 10
open_redirect
Low0.1–3.9 · A05 Security Misconfiguration · CWE-200DetectedResearched · citedWhere / evidence: Requesting /?next=https%3A%2F%2Fevil-test.example.com%2F produced a redirect (HTTP 301) to https://cloviflip.clovitek.com/?next=https%3A%2F%2Fevil-test.example.com%2F — an attacker can craft links on this domain that send victims to an attacker-controlled site (phishing amplification).
Impact: Publicly reachable resource that should not be exposed.
Why it matters: This matters because an **open redirect** lets an attacker use your trusted domain in a link that forwards victims to an attacker-controlled site, which is commonly used for **phishing** and to bypass domain-based trust checks in security-sensitive flows.[1][2] Open redirects are recognized by MITRE as CWE-601, “URL Redirection to Untrusted Site,” and OWASP notes they can be abused to redirect users from a legitimate domain to a malicious destination.[1][2]
1. **Stop redirecting directly from untrusted query parameters** such as `next`, `url`, `redirect`, or similar user-controlled values.[2]
AI Recommended Fix:- This matters because an **open redirect** lets an attacker use your trusted domain in a link that forwards victims to an attacker-controlled site, which is commonly used for **phishing** and to bypass domain-based trust checks in security-sensitive flows.[1][2] Open redirects are recognized by MITRE as CWE-601, “URL Redirection to Untrusted Site,” and OWASP notes they can be abused to redirect users from a legitimate domain to a malicious destination.[1][2]
1. **Stop redirecting directly from untrusted query parameters** such as `next`, `url`, `redirect`, or similar user-controlled values.[2][4]
2. **Replace arbitrary destination URLs with a server-side allowlist or mapping key** so the request carries an opaque identifier and the application resolves it to a pre-approved destination on the server.[2][4][5]
3. **If same-origin redirects are required, allow only relative paths** and reject any value that is not a strict relative URL or does not begin with `/`.[2][4]
4. **If external redirects are unavoidable, validate the parsed URL with a strict hostname allowlist** using the language’s built-in URL parser, not string matching, regex, `contains`, or `startsWith` checks.[2]
5. **Use an interstitial warning page for external destinations** so the user can see the final destination before leaving your domain.[2]
```nginx
# Example: block external redirect targets at the edge; only allow relative paths.
# Replace /redirect or app-specific handler paths with your actual redirect
11
Permissions-Policy header not set
Low0.1–3.9 · A05 Security Misconfiguration · CWE-693DetectedResearched · citedWhere / evidence: HEAD response for the target omitted the Permissions-Policy response header.
Impact: Powerful browser features are not explicitly restricted.
Why it matters: Setting the **Permissions-Policy** header matters because it prevents unauthorized origins and embedded frames from using sensitive browser features (like **geolocation**, **camera**, **microphone**, or **full-screen**), thereby protecting user privacy and reducing the risk of data exploitation via malicious scripts[1][2]. Without this header, any page or iframe can request access to these features, potentially allowing attackers to harvest user data or track behavior without consent[2][5].
### Named fix_steps
1. **Identify necessary features**: Determine which browser features your applica
AI Recommended Fix:- Setting the **Permissions-Policy** header matters because it prevents unauthorized origins and embedded frames from using sensitive browser features (like **geolocation**, **camera**, **microphone**, or **full-screen**), thereby protecting user privacy and reducing the risk of data exploitation via malicious scripts[1][2]. Without this header, any page or iframe can request access to these features, potentially allowing attackers to harvest user data or track behavior without consent[2][5].
### Named fix_steps
1. **Identify necessary features**: Determine which browser features your application legitimately requires (e.g., geolocation for maps, camera for profile uploads) and which should be disabled for all domains[2][3].
2. **Generate the policy string**: Construct a `Permissions-Policy` header value that explicitly disables unused features by setting them to `()` (e.g., `geolocation=(), camera=(), microphone=()`), or restricts them to specific origins if needed[2][5].
3. **Configure your web server**: Add the header to your server configuration (e.g., Apache `mod_headers`, Nginx, IIS, or application framework) so it is sent on **every** HTTP response[2][6].
4. **Validate the configuration**: Use a browser developer tool or security scanner (like OWASP ZAP) to confirm the `Permissions-Policy` header is present and correctly formatted in the HEAD response[6].
5. **Test functionality**: Ensure that disabling features does not break legitimate application functionality
12
Referrer-Policy header not set
Low0.1–3.9 · A01 Broken Access Control · CWE-200DetectedResearched · citedWhere / evidence: HEAD response for the target omitted the Referrer-Policy response header.
Impact: Full referrer URLs may leak to third parties.
Why it matters: The missing **Referrer-Policy** header means browsers fall back to their default referrer behavior, which can leak full URLs (including path and query parameters) to other origins, causing **user and application data exposure (CWE‑200)**.[5][9][10]
---
### 1) Why it matters
- The **Referer** request header contains the URL of the page that initiated a request.[9]
- Without an explicit **Referrer-Policy**, browsers may send the **full URL** (including path and query string) to third‑party sites when users click links, load images, or follow redirects.[9][10]
- If your URLs contain **sens
AI Recommended Fix:- The missing **Referrer-Policy** header means browsers fall back to their default referrer behavior, which can leak full URLs (including path and query parameters) to other origins, causing **user and application data exposure (CWE‑200)**.[5][9][10]
---
### 1) Why it matters
- The **Referer** request header contains the URL of the page that initiated a request.[9]
- Without an explicit **Referrer-Policy**, browsers may send the **full URL** (including path and query string) to third‑party sites when users click links, load images, or follow redirects.[9][10]
- If your URLs contain **sensitive information in paths or query parameters** (tokens, internal IDs, usernames, etc.), this data can be **disclosed to external sites**, violating confidentiality and privacy (CWE‑200: Information Exposure).[3][5][9]
- OWASP’s HTTP Headers Cheat Sheet explicitly recommends setting a **Referrer-Policy** header to control this behavior and suggests `strict-origin-when-cross-origin` as a safe modern default.[5]
- MDN documents that `strict-origin-when-cross-origin` will:
- Send the full URL only for **same-origin** requests.
- Send **only the origin** for cross‑origin requests over the same scheme (HTTPS→HTTPS).
- Send **no referrer** when downgrading (HTTPS→HTTP).[9]
- Security‑header baselines from OWASP Secure Headers and other guidance also include **Referrer-Policy** as a recommended control.[1][4][5]
---
### 2) Fix steps (numbered)
1. **Decide the policy appropriate