Security Assessment Portfolio -- J.M. Field Group

Critical

High

Medium

Info

Findings

High No DMARC Record -- Email Can Be Spoofed With No Policy

fancypetsalon.com has no DMARC record in DNS. While SPF is present with a hard fail (-all), the absence of DMARC means that receiving mail servers have no policy instruction from the domain owner on how to handle SPF/DKIM failures. Attackers can send spoofed emails appearing to come from the domain and many receivers will still deliver them depending on their local policy.

Fix: Add a DMARC TXT record at _dmarc.fancypetsalon.com starting with p=quarantine and an rua= tag pointing to an email address for aggregate reports. After monitoring for two to four weeks with no false positives, upgrade to p=reject.

Medium Missing Content-Security-Policy Header

No Content-Security-Policy header is present in responses. Without CSP, any injected or third-party script has unrestricted ability to execute in the browser context, access cookies, and make requests to external domains.

Fix: Add a CSP header via Cloudflare Transform Rules or at the origin server. Start with default-src 'self' and add specific exceptions for Google Fonts, any analytics, and the booking widget as needed.

Medium Missing Permissions-Policy Header

The Permissions-Policy header is not set. This means any embedded iframe or third-party script could potentially request access to browser APIs such as geolocation, microphone, or camera without explicit permission granted by the page owner.

Fix: Add Permissions-Policy: camera=(), microphone=(), geolocation=() via Cloudflare Transform Rules or origin server configuration to explicitly restrict feature access.

Info admin/ Path Returns HTTP 200

A request to fancypetsalon.com/admin/ returns HTTP 200. Investigation indicates this appears to serve standard site content rather than an administrative panel -- likely due to URL routing returning the main page for unknown paths. This was not confirmed to be an exposed admin interface.

Fix: No action required if confirmed to be the main site content. Verify that no actual admin panel is reachable at this path. If the site has a CMS or admin area, ensure it is protected by authentication and IP restrictions.

Info No security.txt File

No security.txt file is present at /.well-known/security.txt. This file is a standardized way to communicate to security researchers how to report vulnerabilities responsibly.

Fix: Create a security.txt file with a contact email or URL for security disclosures. Use securitytxt.org to generate the file and upload it to the server or configure it via Cloudflare Workers.

Positive Findings

Control	Status
CDN / Proxy	Cloudflare proxy active -- masks origin IP
TLS Version	TLSv1.3 supported
HSTS	Enabled (max-age=15552000)
X-Frame-Options	SAMEORIGIN
X-Content-Type-Options	nosniff
Referrer-Policy	strict-origin-when-cross-origin
HTTP to HTTPS	301 redirect in place
.env Exposure	Returns 403 -- access blocked
.git/config Exposure	Returns 403 -- access blocked
SPF Record	Present with hard fail (-all)

Technology Stack

Category	Technology
Frontend	Static HTML + React
CDN / Proxy	Cloudflare
SSL Certificate	Google Trust Services
Email (MX)	Cloudflare Email Routing
Transactional Email	SMTP2Go

Action Plan

Priority	Action	Where	Effort
1	Add DMARC record: `v=DMARC1; p=quarantine; rua=mailto:dmarc@fancypetsalon.com`	Cloudflare DNS	5 min
2	Add Content-Security-Policy header via Cloudflare Transform Rule	Cloudflare dashboard	15 min
3	Add Permissions-Policy header via Cloudflare Transform Rule	Cloudflare dashboard	5 min
4	Add security.txt file at /.well-known/security.txt	Server deploy	5 min
5	After 2-4 weeks monitoring DMARC reports, upgrade to p=reject	Cloudflare DNS	5 min

Critical

High

Medium

Info

Findings

Critical .env File Was Publicly Accessible -- REMEDIATED During This Scan

At the time of this assessment, the .env file at perfectcopier.com/.env returned HTTP 200 and contained fully exposed credentials. The following sensitive values were confirmed visible: database credentials (username perfectcopier_root with plaintext password), APP_KEY, JWT_SECRET, mail server password, and Sentry DSN. This file was accessible to anyone on the internet. The exposure has been remediated during this scan session via .htaccess block, but all exposed credentials must be treated as compromised and rotated immediately. There is no way to determine whether this file was previously accessed by a malicious actor.

Fix: Verify .htaccess block is in place and .env now returns 403. Rotate ALL exposed credentials immediately: change the database password for perfectcopier_root, regenerate APP_KEY with php8.2 artisan key:generate, regenerate JWT_SECRET, change the mail server password, and revoke the Sentry DSN. Review server access logs for any prior requests to /.env. Update all rotated values in the live .env file on the server.

Critical Zero Security Headers Present

The site returns no security-related HTTP headers whatsoever. There is no HSTS, no X-Frame-Options, no X-Content-Type-Options, no Content-Security-Policy, no Referrer-Policy, and no Permissions-Policy. This is the baseline expected header set for any production web application, and its complete absence means the site is maximally exposed to header-based attacks including clickjacking, MIME sniffing, XSS, and referrer leakage.

Fix: Add all required security headers in the nginx configuration for perfectcopier.com. At minimum: Strict-Transport-Security: max-age=31536000; includeSubDomains, X-Frame-Options: SAMEORIGIN, X-Content-Type-Options: nosniff, Referrer-Policy: strict-origin-when-cross-origin, and a CSP policy appropriate for the Laravel + Angular stack.

High DMARC Set to p=none -- No Email Spoofing Enforcement

The DMARC record for perfectcopier.com is set to p=none, which is monitor-only mode. While this collects aggregate report data, it provides zero enforcement -- spoofed emails impersonating perfectcopier.com will not be quarantined or rejected by receiving mail servers that respect DMARC policy.

Fix: Review DMARC aggregate reports (rua) for two to four weeks to identify all legitimate senders. Once confirmed, upgrade the policy to p=quarantine, then to p=reject after further monitoring.

High SPF Record Includes Decommissioned Server 207.148.5.50

The SPF record for perfectcopier.com explicitly includes the IP address 207.148.5.50, which is the old CentOS 7 server currently being decommissioned. This server is no longer under active management for perfectcopier.com, and its inclusion in SPF means that if the server were to be reassigned or compromised, it would be an SPF-authorized sender for perfectcopier.com email.

Fix: Remove the ip4:207.148.5.50 entry (or the include: that references it) from the SPF record. After removing, verify email deliverability from the remaining authorized senders using an SPF testing tool.

High Debug Header Leaking Internal Path (x-debug-location)

HTTP responses include a custom header x-debug-location: sales-dashboard-prefix. This is a debug or diagnostic header that was left active in the production nginx or Laravel configuration. It exposes internal routing information to anyone who inspects response headers, assisting attackers in mapping the application structure.

Fix: Remove the debug header from the nginx server block configuration. If this header was added in Laravel middleware or a service provider, remove it from the production code path. Audit all response headers for any other debug or diagnostic values.

Medium Self-Signed Origin SSL Certificate (Behind Cloudflare)

The origin server uses a self-signed SSL certificate. While Cloudflare's proxy layer provides a valid certificate to end users, the connection between Cloudflare and the origin server is either unencrypted or using a self-signed certificate that Cloudflare cannot fully validate. If Cloudflare SSL mode is set to "Flexible," traffic between Cloudflare and origin travels over HTTP. Even in "Full" mode, the self-signed cert cannot be verified, leaving the connection susceptible to interception.

Fix: Replace the self-signed certificate with a Cloudflare Origin CA certificate. This is a free certificate issued by Cloudflare specifically for securing the Cloudflare-to-origin connection. Set Cloudflare SSL mode to "Full (strict)" after installing the Origin CA cert.

Medium Root Domain Redirects to /sales-dashboard/ -- No Proper Homepage

Navigating to perfectcopier.com redirects immediately to /sales-dashboard/, which appears to be an internal application panel. There is no public-facing homepage or landing page. This exposes the application entry point directly to unauthenticated users and reduces the perceived legitimacy of the domain.

Fix: Configure a proper public landing page at the root, or add Cloudflare Access authentication in front of the /sales-dashboard/ path to require login before the application is reachable. At minimum, ensure the dashboard page itself requires authentication before rendering any content.

Info 20 Subdomains Visible in Certificate Transparency Logs

Certificate transparency logs show approximately 20 subdomains registered for perfectcopier.com, including test, demo, and node environments. These subdomains may represent staging or development environments that have not received the same security attention as the production site.

Fix: Audit all subdomains. Decommission any that are no longer needed. Apply authentication and security headers to all active subdomains, particularly test and staging environments which often contain older code versions with known vulnerabilities.

Info No security.txt File

No security.txt file is present at /.well-known/security.txt, making it unclear how security researchers should report vulnerabilities.

Fix: Add a security.txt file with a contact email for responsible disclosure reports.

Positive Findings

Control	Status
TLS Version	TLSv1.3 supported
CDN / Proxy	Cloudflare proxy active
SPF Record	Present (soft fail ~all -- upgrade to -all recommended)
.git/config Exposure	Returns 403 -- access blocked

Technology Stack

Category	Technology
Framework	Laravel + Tailwind CSS
Web Server	nginx
CDN / Proxy	Cloudflare
SSL Certificate	Self-signed origin certificate (replace with Cloudflare Origin CA)
Transactional Email	Brevo, SMTP2Go

Action Plan

Priority	Action	Where	Effort
1	IMMEDIATE: Rotate ALL exposed credentials -- DB password, APP_KEY, JWT_SECRET, mail password. Regenerate with `php8.2 artisan key:generate`	Server 45.63.111.108	30 min
2	Review server access logs for prior requests to /.env to assess if credentials were harvested	Server logs	15 min
3	Add all security headers in nginx: HSTS, X-Frame-Options, X-Content-Type-Options, CSP, Referrer-Policy, Permissions-Policy	nginx config on CloudPanel	20 min
4	Remove debug header (x-debug-location) from nginx/Laravel	nginx config or middleware	5 min
5	Remove 207.148.5.50 from SPF record	Cloudflare DNS	5 min
6	Upgrade DMARC from p=none to p=quarantine	Cloudflare DNS	5 min
7	Replace self-signed origin cert with Cloudflare Origin CA cert, set SSL to Full (strict)	CloudPanel + Cloudflare	20 min
8	Add proper landing page or Cloudflare Access auth for /sales-dashboard/	Laravel routes or Cloudflare Access	30 min
9	Audit and decommission unused subdomains (test, demo, node, nodejs)	CloudPanel + DNS	15 min

Critical

High

Medium

Info

Findings

High DMARC pct=0 -- Reject Policy Exists But Enforcement Is Disabled

The DMARC record for jmfield.com includes p=reject, which appears secure, but also contains pct=0. The pct= tag controls what percentage of failing messages the policy is applied to. A value of 0 means the policy is effectively disabled -- zero percent of spoofed emails will be rejected. This is a common misconfiguration that gives a false sense of security in automated security scans while providing no actual protection.

Fix: Change pct=0 to pct=100 in the DMARC DNS record. If pct=0 was set intentionally to test without enforcement, it should be incrementally increased to 25, 50, then 100 over the course of several weeks while monitoring aggregate reports for legitimate-sender false positives.

Medium Missing Referrer-Policy Header

The site does not set a Referrer-Policy header. Without this, browsers send the full URL in the Referer header when users navigate from jmfield.com to external sites. This may expose internal page paths or query parameters to third-party servers.

Fix: Add Referrer-Policy: strict-origin-when-cross-origin via LiteSpeed configuration or Cloudflare Transform Rules.

Medium Missing Permissions-Policy Header

The Permissions-Policy header is not present, leaving browser feature access unrestricted for the page and any embedded third-party content.

Fix: Add a Permissions-Policy header explicitly restricting features not used by the site, such as camera, microphone, and geolocation. This can be configured via LiteSpeed configuration or Cloudflare Transform Rules.

Medium CSP Contains Only upgrade-insecure-requests -- No Script or Style Restrictions

A Content-Security-Policy header is present, but it only contains the upgrade-insecure-requests directive. This directive upgrades HTTP sub-resources to HTTPS but provides no protection against XSS or unauthorized script execution. A CSP without script-src, style-src, or default-src directives is not a functional content security policy.

Fix: Expand the CSP to include at minimum default-src 'self' along with specific exceptions for WordPress assets, any Google Fonts or Analytics, LiteSpeed Cache resources, and any other third-party scripts used by the site. Begin testing in report-only mode (Content-Security-Policy-Report-Only) to identify required exceptions before enforcing.

Info WordPress REST API Exposed via Link Headers

HTTP response headers include a Link header advertising the WordPress REST API endpoint at /wp-json/. While the REST API itself is not inherently dangerous, its public exposure allows automated tools to enumerate installed plugins, active themes, user accounts, and content structure, which assists in targeted attacks against the WordPress installation.

Fix: If the REST API is not required for public use (e.g., no public-facing app consumes it), restrict access to authenticated requests. Remove the Link header advertisement by adding a filter in WordPress: remove_action('template_redirect', 'rest_output_link_header', 11, 0);

Info No security.txt File

No security.txt file is published at /.well-known/security.txt for responsible disclosure guidance.

Fix: Create a security.txt file with contact information for vulnerability reports.

Positive Findings

Control	Status
WAF	Cloudflare + Sucuri dual WAF protection
TLS Version	TLSv1.3 supported
HSTS	Enabled with includeSubDomains
X-Frame-Options	SAMEORIGIN
X-Content-Type-Options	nosniff
X-XSS-Protection	1; mode=block
HTTP to HTTPS	301 redirect in place
.env Exposure	Returns 403 -- access blocked
.git/config Exposure	Returns 403 -- access blocked
wp-login.php	Returns 404 -- login path obscured
Caching Plugin	LiteSpeed Cache active

Technology Stack

Category	Technology
CMS	WordPress
CDN / Proxy	Cloudflare
WAF	Sucuri WAF (in addition to Cloudflare)
Web Server	LiteSpeed
SSL Certificate	Let's Encrypt
Email (MX)	Microsoft Outlook (Exchange Online)
Transactional Email	Amazon SES

Action Plan

Priority	Action	Where	Effort
1	Change DMARC pct=0 to pct=100 to actually enforce the reject policy	DNS (Cloudflare or registrar)	5 min
2	Add Referrer-Policy: strict-origin-when-cross-origin via Cloudflare Transform Rule	Cloudflare dashboard	5 min
3	Add Permissions-Policy header via Cloudflare Transform Rule	Cloudflare dashboard	5 min
4	Expand CSP beyond upgrade-insecure-requests -- add default-src, script-src, style-src (start in report-only mode)	Sucuri WAF or Cloudflare	30 min
5	Suppress WP REST API Link header: add `remove_action('template_redirect', 'rest_output_link_header', 11, 0)`	WordPress functions.php or Sucuri	5 min
6	Add security.txt file at /.well-known/security.txt	cPanel / WordPress	5 min

Critical

High

Medium

Info

Findings

High Missing X-Frame-Options Header -- Clickjacking Risk

The site does not return an X-Frame-Options header, which means it can be embedded in an iframe on any third-party website. While devsite.jmfield.com is a staging site, it contains a full preview of the J.M. Field relaunch design and any forms or interactive elements it hosts could be exploited via clickjacking if an attacker lured staff members to a malicious page.

Fix: Add X-Frame-Options: SAMEORIGIN to the LiteSpeed virtual host configuration or via Cloudflare Transform Rules. Alternatively, add frame-ancestors 'self' in a Content-Security-Policy header.

High Missing Content-Security-Policy Header

No Content-Security-Policy header is present. Although this is a staging environment with static HTML content and a minimal attack surface, the absence of CSP means that if any script injection were to occur via the deployment pipeline or a third-party resource, it would execute without restriction.

Fix: Add a CSP header via LiteSpeed configuration or Cloudflare Transform Rules. For a static site, a strict policy such as

default-src 'self'; script-src 'self'; style-src 'self' https://fonts.googleapis.com; font-src 'self' https://fonts.gstatic.com

is achievable without significant exception management.

Medium Missing Referrer-Policy Header

No Referrer-Policy header is set. Browsers will send the full Referer header by default on cross-origin navigation, potentially exposing staging URL patterns to any external resources linked from the preview site.

Fix: Add Referrer-Policy: strict-origin-when-cross-origin to the server or Cloudflare configuration.

Medium Missing Permissions-Policy Header

The Permissions-Policy header is absent, leaving browser feature APIs unrestricted. For a static staging site this is low risk, but the header should be included as a matter of consistent security posture across all J.M. Field properties.

Fix: Add a Permissions-Policy header restricting unused browser features. This can be configured globally in the LiteSpeed vhost or via a Cloudflare Transform Rule applied to the devsite subdomain.

Info Server Identifies as LiteSpeed via x-turbo-charged-by Header

The response includes the header x-turbo-charged-by: LiteSpeed, which discloses the web server software in use. While LiteSpeed is not inherently sensitive information, disclosing the server type allows attackers to narrow their focus to LiteSpeed-specific vulnerabilities or configuration weaknesses.

Fix: Suppress the x-turbo-charged-by header in LiteSpeed configuration if possible. This is a minor hardening step and lower priority than the header findings above.

Positive Findings

Control	Status
CDN / Proxy	Cloudflare proxy active
TLS Version	TLSv1.3 supported
HSTS	Enabled with includeSubDomains
X-Content-Type-Options	nosniff
.env Exposure	Returns 404 -- file not present
.git/config Exposure	Returns 404 -- file not present
HTTP to HTTPS	301 redirect in place
Attack Surface	Static HTML -- no server-side execution or database

Technology Stack

Category	Technology
Frontend	Static HTML
Web Server	LiteSpeed
CDN / Proxy	Cloudflare
SSL Certificate	Let's Encrypt (shared certificate with jmfield.com)

Action Plan

Priority	Action	Where	Effort
1	Add X-Frame-Options: SAMEORIGIN via Cloudflare Transform Rule or LiteSpeed config	Cloudflare or cPanel/LiteSpeed	5 min
2	Add Content-Security-Policy header (static site = strict policy possible: default-src 'self'; script-src 'self'; style-src 'self' fonts.googleapis.com)	Cloudflare or LiteSpeed	15 min
3	Add Referrer-Policy: strict-origin-when-cross-origin	Cloudflare or LiteSpeed	5 min
4	Add Permissions-Policy header	Cloudflare or LiteSpeed	5 min
5	Suppress x-turbo-charged-by header if LiteSpeed allows	LiteSpeed config	5 min

Critical

High

Medium

Info

Findings

Critical No HTTP-to-HTTPS Redirect -- HTTP Port 80 Serves Content

Requests to http://med-vision.com on port 80 receive a full HTML response instead of a redirect to HTTPS. This means users who type the domain without https:// or follow an HTTP link will use an unencrypted connection. All form submissions, session cookies, and page content traversed over HTTP are visible to anyone on the network path between the user and the server.

Fix: Add a 301 redirect from HTTP to HTTPS in the server configuration. If using Cloudflare, enable the "Always Use HTTPS" setting under SSL/TLS. Alternatively, add a server block in nginx that listens on port 80 and returns a 301 redirect to the https:// equivalent URL.

High No DMARC Record -- Complete Email Spoofing Exposure

med-vision.com has no DMARC DNS record at all. Combined with the absence of enforcement mechanisms, any attacker can send email claiming to be from @med-vision.com with no policy-based rejection. For a healthcare consulting firm where email communication is central to client trust, this is a significant brand and phishing risk.

Fix: Add a DMARC TXT record at _dmarc.med-vision.com. Start with p=quarantine and an rua= tag for aggregate reports. Monitor reports for two to four weeks to confirm all legitimate senders pass SPF or DKIM, then upgrade to p=reject.

High Missing HSTS Header

The site does not return a Strict-Transport-Security header. Without HSTS, browsers do not remember to enforce HTTPS for the domain, and SSL stripping attacks are possible on the initial (or any non-cached) connection. This is compounded by the fact that HTTP is already serving content (see Critical finding above).

Fix: After resolving the HTTP redirect issue, add Strict-Transport-Security: max-age=31536000; includeSubDomains to the HTTPS response headers. This can be set in Kinsta's nginx configuration or via Cloudflare's response header transform rules.

High wp-login.php Returns HTTP 200 -- WordPress Login Publicly Accessible

The WordPress login page at med-vision.com/wp-login.php is publicly accessible and returns a valid 200 response with the login form. This exposes the site to automated brute-force and credential stuffing attacks. Given that the site uses a headless WordPress backend, there is even less reason for the wp-login.php endpoint to be publicly reachable.

Fix: Restrict access to wp-login.php by IP address using nginx configuration, Kinsta's security rules, or Cloudflare Access. Alternatively, implement two-factor authentication for all WordPress users via a plugin such as WP 2FA. Add rate limiting to wp-login.php to throttle brute-force attempts.

Medium Multiple Missing Security Headers (X-Frame-Options, CSP, Referrer-Policy, Permissions-Policy)

The site is missing four common security headers: X-Frame-Options (clickjacking protection), Content-Security-Policy (XSS mitigation), Referrer-Policy (referrer leakage control), and Permissions-Policy (browser feature access control). The absence of all four indicates that security headers have not been configured at the server or application layer.

Fix: Add all four headers via Kinsta's custom header configuration or via Cloudflare Transform Rules. For CSP, begin in report-only mode to identify required exceptions for the Astro/Next.js frontend and any third-party scripts before enforcing.

Medium .env and .git/config Return 403 -- Files Likely Exist on Disk

Requests to /.env and /.git/config return HTTP 403 Forbidden responses rather than 404 Not Found. A 403 response typically indicates that the file exists on disk and the server is blocking access by permission rules. While the file is not readable, confirming its existence on a production server is a concern -- .env files should not be in the web root, and .git directories should not exist in deployed production environments.

Fix: Verify whether .env and .git/ are actually present in the Kinsta web root for this site. If present, the .env file should be moved outside the web root entirely (not merely blocked), and the .git directory should be deleted from the production deployment. Deploying without the .git directory is best practice -- use a CI/CD pipeline that copies only built artifacts to the server.

Info Kinsta Hosting Details Leaked via Response Headers

HTTP responses include Kinsta-specific headers such as ki-edge and x-kinsta-cache. These headers disclose that the site is hosted on Kinsta's managed WordPress platform, which narrows the attack surface for platform-specific exploits or social engineering of Kinsta support channels.

Fix: Check whether Kinsta provides an option to suppress platform-identifying headers. This is a low-priority informational item and does not require immediate action.

Info No security.txt File

No security.txt file is present at /.well-known/security.txt for responsible disclosure contact information.

Fix: Add a security.txt file with a contact email or URL for reporting security vulnerabilities.

Positive Findings

Control	Status
CDN / Proxy	Cloudflare proxy active
TLS Version	TLSv1.3 supported
X-Content-Type-Options	nosniff
SSL Certificate	Google Trust Services (valid)
Cookie Flags	HttpOnly + Secure + SameSite=None flags set

Technology Stack

Category	Technology
CMS / Backend	WordPress (headless)
Frontend Framework	Astro / Next.js
Hosting	Kinsta managed WordPress
CDN / Proxy	Cloudflare
SSL Certificate	Google Trust Services
Email (MX)	Google Workspace (smtp.google.com)

Action Plan

Priority	Action	Where	Effort
1	IMMEDIATE: Enable HTTP-to-HTTPS redirect -- turn on "Always Use HTTPS" in Cloudflare SSL/TLS settings	Cloudflare dashboard	2 min
2	Add DMARC record: `v=DMARC1; p=quarantine; rua=mailto:dmarc@med-vision.com`	Cloudflare DNS	5 min
3	Add HSTS header via Cloudflare Transform Rule or Kinsta config	Cloudflare or Kinsta	5 min
4	Restrict wp-login.php access -- add IP allowlist, 2FA, or Cloudflare Access	Kinsta security rules or Cloudflare Access	20 min
5	Add security headers: X-Frame-Options, CSP, Referrer-Policy, Permissions-Policy	Cloudflare Transform Rules	15 min
6	Delete .env and .git/ from Kinsta web root (should not exist in production)	Kinsta SFTP or SSH	10 min
7	After 2-4 weeks, upgrade DMARC to p=reject	Cloudflare DNS	5 min
8	Add security.txt file	Kinsta or WordPress	5 min

Critical

High

Medium

Info

Findings

Medium Missing Content-Security-Policy Header

No Content-Security-Policy header is present in responses from myseodesk.com. While the site has an excellent baseline of other security headers, the absence of CSP leaves the site without browser-enforced protection against cross-site scripting attacks. The site includes a PHP-powered AI chatbot endpoint (Groq API), making script injection defense more relevant than for a fully static site.

Fix: Add a CSP header via nginx (CloudPanel) configuration. Start with default-src 'self' and add exceptions for Tailwind CDN, Google Fonts, and any external scripts. Test in report-only mode first to identify required sources without breaking functionality.

Medium Missing Permissions-Policy Header

The Permissions-Policy header is not present. Although the site has strong headers in most other categories, Permissions-Policy is a standard complement to the existing security header set and should be added for completeness and defense in depth.

Fix: Add Permissions-Policy: camera=(), microphone=(), geolocation=() to the nginx configuration for myseodesk.com on CloudPanel.

Medium DMARC Set to p=none -- Monitor Only, No Enforcement

The DMARC record for myseodesk.com is set to p=none, which collects aggregate report data but does not instruct receiving mail servers to quarantine or reject messages that fail SPF/DKIM alignment. Spoofed emails claiming to be from the domain can still be delivered to recipients without any policy-based intervention.

Fix: Review DMARC aggregate reports at the rua= address to identify all sending mail services (currently Cloudflare Email Routing, Brevo, SMTP2Go). Once confirmed that all legitimate senders pass DMARC alignment, upgrade the policy to p=quarantine, then to p=reject after a further monitoring period.

Info 11 Subdomains Visible in Certificate Transparency Logs

Certificate transparency logs reveal 11 subdomains for myseodesk.com, including git (Gitea), voip, ringnow, workflow, and med-vision. While these subdomains correspond to known active services, their presence in public CT logs maps the infrastructure for any interested party. Some subdomains such as ringnow and workflow may be development or experimental environments with less hardening than production.

Fix: Audit each subdomain for appropriate security headers, authentication, and SSL configuration. Decommission any subdomains that are no longer in active use. Consider whether any subdomains that should not be publicly discoverable could be moved to internal DNS or accessed via VPN only.

Info No security.txt File

No security.txt file is published at /.well-known/security.txt for responsible disclosure.

Fix: Add a security.txt file with a contact email. Given that myseodesk.com is used as a developer portfolio and hosts multiple subservices, publishing a security contact is good practice.

Positive Findings

Control	Status
HSTS	Enabled with includeSubDomains
X-Frame-Options	SAMEORIGIN
X-Content-Type-Options	nosniff
X-XSS-Protection	1; mode=block
Referrer-Policy	same-origin
X-Permitted-Cross-Domain-Policies	master-only
HTTP to HTTPS	301 redirect in place
.env Exposure	Returns 404 -- not accessible
.git/config Exposure	Returns 404 -- not accessible
Other Sensitive Paths	All sensitive paths return 404
CDN / Proxy	Cloudflare proxy active
TLS Version	TLSv1.3 supported
SPF Record	Present

Technology Stack

Category	Technology
Frontend	Static HTML + PHP + Tailwind CSS
Web Server	nginx (CloudPanel)
CDN / Proxy	Cloudflare
SSL Certificate	Google Trust Services
Email (MX)	Cloudflare Email Routing
Transactional Email	Brevo, SMTP2Go

Action Plan

Priority	Action	Where	Effort
1	Add Content-Security-Policy header in nginx (default-src 'self'; script-src 'self' 'unsafe-inline'; style-src 'self' 'unsafe-inline' fonts.googleapis.com cdn.tailwindcss.com)	CloudPanel nginx config	15 min
2	Add Permissions-Policy: camera=(), microphone=(), geolocation=()	CloudPanel nginx config	5 min
3	Upgrade DMARC from p=none to p=quarantine (review Brevo/SMTP2Go reports first)	Cloudflare DNS	5 min
4	Audit subdomains: decommission ringnow, screensareus, mobile-detail if unused	CloudPanel + Cloudflare DNS	10 min
5	Add security.txt file at /.well-known/security.txt	Server deploy	5 min
6	After 2-4 weeks, upgrade DMARC to p=reject	Cloudflare DNS	5 min