The security scan of xturbo.com.br found 19 medium and low severity issues. No critical vulnerabilities were detected, but 6 issues should be addressed this week to harden your security posture. Detailed fix instructions are included for each finding.
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.
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.
DMARC is set to monitor-only (p=none) — phishing emails pretending to be you aren't blocked, just reported
Phishing emails pretending to be your business can still reach customers' inboxes today — you'll get aggregate reports about it after the fact (if 'rua=' reporting is configured), but nothing actually stops the fraudulent emails from being delivered right now. p=none is a legitimate and recommended first step — it lets you review reports and confirm all your real mail sources pass DMARC alignment (the From-header domain matching either an aligned SPF pass or an aligned DKIM signature) before you start blocking anything — the risk is only in staying at p=none indefinitely instead of using it as a monitoring phase.
Example: Forged emails impersonating the business keep reaching customers' inboxes; DMARC reports quietly pile up showing exactly that it's happening, but because the policy is monitor-only, nothing actually blocks a single one of them.
Review DMARC aggregate reports (they require 'rua=mailto:...' in the record — this record doesn't appear to have one, add it first) for a few weeks to confirm every legitimate mail source for this domain is passing DMARC alignment. Once confirmed, move to 'p=quarantine' (suspicious mail goes to spam) and monitor again before finally moving to 'p=reject' (spoofed mail is rejected outright). Don't jump straight to p=reject — if a legitimate sender was missed, that skips straight to real mail being dropped. Example: 'v=DMARC1; p=quarantine; rua=mailto:dmarc@yourdomain.com'
CWE-290 — Authentication Bypass by Spoofing
The login or identity check can be tricked by faking trusted information, letting an attacker in without real credentials.
CSP is set but has no script-src or default-src directive — script execution isn't restricted at all
If an attacker compromises any third-party script you load — a classic 'watering hole' tactic, where they hijack a widget or library your site trusts instead of attacking you directly — nothing stops that code from running on every visitor's browser and stealing logins or payment data.
Example: A third-party widget the site trusts and loads on every page gets compromised by attackers upstream; because nothing restricts which scripts can run, the malicious update executes on every visitor's browser the next time they load the page.
Add a script-src directive listing only the exact domains you actually load scripts from, e.g. "script-src 'self' https://cdn.yourtrustedvendor.com;". Avoid 'unsafe-inline' and wildcards.
CWE-693 — Protection Mechanism Failure
A security safeguard that should be protecting the system is missing, disabled, or not strong enough.
3 third-party script source(s) loaded without Subresource Integrity (SRI): cdnjs.cloudflare.com, www.googletagmanager.com, xturbo.matrixdobrasil.ai
If any of these third-party providers is ever compromised — a real, recurring attack pattern called a 'watering hole' or supply-chain attack, where attackers hit a widely-trusted vendor instead of you directly — the malicious code they inject would run on your site with no verification and no warning to you or your visitors.
Example: A widely-used analytics or widget provider gets compromised (a real, recurring attack pattern), and because the script loads without integrity verification, the malicious version executes on every visitor's browser with no warning to you or them.
Add integrity and crossorigin attributes to each third-party <script> tag, e.g. <script src="..." integrity="sha384-..." crossorigin="anonymous"></script>. Most CDNs (cdnjs, jsdelivr, unpkg) publish the correct hash on their site — copy it directly.
CWE-353 — Missing Support for Integrity Check
There's no way to verify that data wasn't altered in transit, so tampering would go unnoticed.
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.
X-Powered-By header discloses your tech stack (PHP/8.2.30) — makes targeted attacks easier
Knowing your exact tech stack lets an attacker focus their effort on vulnerabilities specific to that platform, slightly increasing the odds of being targeted compared to a generic, unidentified site.
Example: Knowing the exact framework and version in use, an attacker skips general reconnaissance and goes straight to testing the specific, publicly known weaknesses for that platform.
Remove the X-Powered-By header. PHP: set 'expose_php = Off' in php.ini. Node/Express: 'app.disable("x-powered-by")'. Nginx: 'more_clear_headers X-Powered-By;' (with headers_more module) or handle in your app.
CWE-200 — Exposure of Sensitive Information
The system reveals information to someone who shouldn't have access to it.
Public IP 147.79.94.195 (hosted by Brander Group Inc.) has no abuse reports on AbuseIPDB in the last 90 days.
A clean IP reputation is a good sign — no other indication needed here.
No action required.
Public IP 147.79.94.195 is registered to Private Customer (BR) — network: HOSTINGER-HOSTING — block: 147.79.88.0 – 147.79.95.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.
Detected technology stack: Php 8.2.30, Wordpress 7.0.2, Jquery 2.0.3.
Knowing your exact software versions helps attackers pick targeted exploits instead of guessing — this isn't a vulnerability by itself, but it's worth knowing what your site publicly reveals about its own software.
No action required unless you'd prefer to hide version banners (e.g. removing WordPress's generator meta tag and readme.html, or disabling Apache/nginx's Server header version string) to make automated targeting slightly harder. Keeping the software itself patched matters far more than hiding the version number.
/.env returned HTTP 403. This confirms the path exists, but access control prevented access — it was not accessed.
/.env returned HTTP 403. This confirms the path exists, but access control prevented access — it was not accessed.
No action needed if this is intentionally restricted. Confirm the credentials protecting it are strong and not left at a default.
/.git/HEAD returned HTTP 403. This confirms the path exists, but access control prevented access — it was not accessed.
/.git/HEAD returned HTTP 403. This confirms the path exists, but access control prevented access — it was not accessed.
No action needed if this is intentionally restricted. Confirm the credentials protecting it are strong and not left at a default.
/.git/config returned HTTP 403. This confirms the path exists, but access control prevented access — it was not accessed.
/.git/config returned HTTP 403. This confirms the path exists, but access control prevented access — it was not accessed.
No action needed if this is intentionally restricted. Confirm the credentials protecting it are strong and not left at a default.
/.svn/entries returned HTTP 403. This confirms the path exists, but access control prevented access — it was not accessed.
/.svn/entries returned HTTP 403. This confirms the path exists, but access control prevented access — it was not accessed.
No action needed if this is intentionally restricted. Confirm the credentials protecting it are strong and not left at a default.
/.htpasswd returned HTTP 403. This confirms the path exists, but access control prevented access — it was not accessed.
/.htpasswd returned HTTP 403. This confirms the path exists, but access control prevented access — it was not accessed.
No action needed if this is intentionally restricted. Confirm the credentials protecting it are strong and not left at a default.
The target began responding with repeated rate-limit/unavailable statuses, so the remaining 89 path(s) in this scan were skipped rather than risk overloading the server.
The target began responding with repeated rate-limit/unavailable statuses, so the remaining 89 path(s) in this scan were skipped rather than risk overloading the server.
Re-run content discovery later, or use a lower-concurrency profile.
No high-risk open ports were detected from the internet — your firewall appears to be blocking dangerous services.