Opening the security report for www.plb.ucdavis.edu
www.plb.ucdavis.edu
Loading the security report for www.plb.ucdavis.edu
www.plb.ucdavis.edu
Is www.plb.ucdavis.edu Safe? Security Score 92/100 | CyStack
www.plb.ucdavis.edu
What to Know About Processed and Ultra-Processed Food
Scientists explain the difference between whole, processed and ultra-processed foods. Learn how they could affect our health and how the food industry can improve.
Industry
Science and Education / Universities and Colleges
Origin
United States
Global rank
#6,042
Rank in United States
#1,372
Updated at
A92/100
Security level
Excellent
Data confidence
High
Scope checked
96.4%
The higher the score, the more externally observable protections the system has recorded. This page does not certify that the website is reputable, legitimate, or completely free of vulnerabilities.
Is the website “www.plb.ucdavis.edu” safe?
As of September 21, 2026 at 10:02, www.plb.ucdavis.edu has a security score of 92/100 (grade A: “Excellent”). CyStack’s automated assessment recorded 8 issues to review after completing 96.4% of applicable checks. The website owner should address “Allowed browser content (CSP)” first, then review the remaining items in order of impact.
Does www.plb.ucdavis.edu show known scam, phishing, or malware signals?
At assessment time, CyStack did not find www.plb.ucdavis.edu or related infrastructure on any scam, phishing, or malware warning list after checking 5 online reputation sources. This result reflects external observations; it does not guarantee absolute safety or verify the organization’s legal status or reputation.
Compare the security level of each assessed category at a glance.
Network attack surface95.2/100 · Good95.5% of this category was checked
Web security87.5/100 · Good100% of this category was checked
Frequently asked questions
What affects the security of www.plb.ucdavis.edu?
A valid SSL certificate still does not prove that www.plb.ucdavis.edu is safe, legitimate, or free of scam signals. For a more complete assessment, this report also checks phishing and malware, exposed email records, IPs and open ports, subdomains, technologies, and CVEs that may apply to observed versions.
Does www.plb.ucdavis.edu use HTTPS, and is its SSL certificate valid?
HTTPS on www.plb.ucdavis.edu presented a certificate that was invalid or failed verification. The operator should review its validity dates, domain names, and trust chain.
Data compiled from CyStack cybersecurity monitoring systems
CyStack compiles scan results from its internal cybersecurity monitoring systems, including CyStack VulnScan and CyStack Threat Intelligence, together with publicly available Internet data. The assessment only observes and analyzes information already available; it does not attempt unauthorized access, test passwords, send exploit code, or change or disrupt the assessed system.
These 3 failed checks or warnings have the greatest impact on the result for www.plb.ucdavis.edu.
Allowed browser content (CSP)The CSP on the inspected root HTML response contains a broad, unsafe, or missing script-source control recognized by this bounded check.High
Why it matters
Content Security Policy (CSP) limits where scripts, styles, frames, and other browser content may come from. A strong policy reduces the impact if an attacker manages to inject content into a page.
What to do
Define only the sources the application needs, test the policy before activating it, and avoid broad wildcard (*) rules, unsafe-inline, and unsafe-eval where possible.
Scope of this check
This check only evaluates the homepage response and content that the scanner could reach. Other pages and sign-in flows may use different settings.
DMARC blocking policyThe effective DMARC policy is quarantine and applies to 100% of messages.High
Why it matters
A policy of quarantine or reject tells receiving services to move suspicious mail to spam or refuse it. A monitoring-only policy (p=none) records the problem but does not ask receivers to stop spoofed mail.
What to do
After every legitimate sender passes DMARC, move gradually to quarantine and then reject, covering 100% of messages.
HSTS availabilityThe HTTPS response does not contain an effective HSTS policy.Medium
Why it matters
HTTP Strict Transport Security (HSTS) tells a browser to use HTTPS automatically on future visits. This reduces the chance that a visitor is downgraded to an unencrypted connection.
What to do
After confirming that every required page works over HTTPS, send the Strict-Transport-Security header on all HTTPS responses.
Transport encryption91.9/100 · Good100% of this category was checked
Threat reputation100/100 · Good100% of this category was checked
Vulnerability and technology risk100/100 · Good100% of this category was checked
Email authentication85.7/100 · Good100% of this category was checked
Data exposure50/100 · Review100% of this category was checked
Domain and DNS hygiene95/100 · Good55.6% of this category was checked
Items to fix or review
This list contains only failed checks and warnings. Checks without enough evidence are grouped separately below.
The CSP on the inspected root HTML response contains a broad, unsafe, or missing script-source control recognized by this bounded check.
Why it matters
Content Security Policy (CSP) limits where scripts, styles, frames, and other browser content may come from. A strong policy reduces the impact if an attacker manages to inject content into a page.
What to do
Define only the sources the application needs, test the policy before activating it, and avoid broad wildcard (*) rules, unsafe-inline, and unsafe-eval where possible.
Scope of this check
This check only evaluates the homepage response and content that the scanner could reach. Other pages and sign-in flows may use different settings.
Evidence and check scope
Configured:
Yes
Number of policies:
1
Weak settings found:
Unsafe Eval
Response inspected:
Homepage HTML response
Host requested:
www.plb.ucdavis.edu
Host observed:
www.plb.ucdavis.edu
References
DMARC blocking policyEmail protectionNeeds review
Check result
The effective DMARC policy is quarantine and applies to 100% of messages.
Why it matters
A policy of quarantine or reject tells receiving services to move suspicious mail to spam or refuse it. A monitoring-only policy (p=none) records the problem but does not ask receivers to stop spoofed mail.
HSTS availabilityHTTPS and encryptionFailed
Check result
The HTTPS response does not contain an effective HSTS policy.
Why it matters
HTTP Strict Transport Security (HSTS) tells a browser to use HTTPS automatically on future visits. This reduces the chance that a visitor is downgraded to an unencrypted connection.
CyStack confirmed at least 1363 active DNS subdomains of ucdavis.edu. 26 names may expose sensitive services; discovery was partial, so more may exist.
Why it matters
Names containing admin, development, staging, VPN, database, or monitoring terms may point attackers toward valuable systems. A name alone does not prove exposure, but it identifies a surface that should be reviewed.
SPF protection levelEmail protectionNeeds review
Check result
The terminal SPF policy is ~all.
Why it matters
The final SPF rule tells receiving services how confidently they should reject unlisted senders. A permissive result allows more spoofed mail to appear legitimate than a hard fail (-all).
1,352 email exposure records ending in @ucdavis.edu are associated with approximately 151 infected devices. These are intelligence observations; they do not prove that the email accounts are still active or that the devices belong to the organization.
The inspected root HTML response sets Permissions-Policy, but its bounded syntax check failed.
Why it matters
Permissions-Policy can further restrict browser features such as the camera, microphone, and location for this page and embedded content. Each feature already has a browser-defined default allowlist, so an absent header does not mean that every feature is unrestricted.
DNS response protection (DNSSEC)Domain and DNSNeeds review
Check result
No DNSSEC DS delegation was found.
Why it matters
DNSSEC adds digital signatures so resolvers can detect forged DNS answers. This quick check looks for a DS record at the parent domain; a passing result confirms that delegation signal, but it does not validate the complete signature chain.
Inconclusive checks (3)These checks lack reliable evidence. They are neither confirmed issues nor passed checks.
Domain registration expiryDomain and DNSUnknown
Check result
The assessment could not determine whether the domain registration is valid beyond the near-term renewal threshold.
Why it matters
An expired domain stops directing users to the organization's services and may eventually become available to someone else. A domain close to expiry leaves little time to recover from payment or account problems.
Diagnostic information
The domain-registration source did not return enough reliable evidence.
Domain registration statusDomain and DNSUnknown
Check result
The assessment could not determine whether the registration status contains no hold, redemption, or pending-deletion signal recognized by this check.
Why it matters
Registrar or registry restrictions such as hold, redemption, or pending deletion can disable the domain. If they are not resolved, the organization may lose control of its website and email identity.
Diagnostic information
The domain-registration source did not return enough reliable evidence.
Unnecessary public servicesPublic infrastructureUnknown
Check result
The service was observed on shared edge infrastructure and cannot be reliably attributed to this domain.
Why it matters
Every open service can be discovered and attacked and must be configured, monitored, and patched. Services without a clear public purpose add risk without providing business value.
Diagnostic information
The service was observed on shared edge infrastructure and cannot be attributed safely to this domain alone.
Evidence and check scope
Complete:
Yes
Ports checked:
21, 22, 23, 25, 53, 80, 110, 111, 139, 143… and 48 more
Informational checks (4)These neutral observations add context and are counted as neither passed checks nor confirmed issues.
Blacklist check coverageIP reputationInformation
Check result
5 providers were definitive and 1 were inconclusive.
Why it matters
This shows how many independent blacklist services returned a clear result. A service that was unavailable was not checked successfully and must not be treated as a clean result.
Evidence and check scope
IPv4 addresses checked:
2
Blocklists reporting an issue:
0
Blocklists with no match:
5
Blocklists unavailable:
1
Blocklists checked conclusively:
5
Confirmed blocklist matches:
No
Technologies visible from the InternetSoftware vulnerabilitiesInformation
Check result
The public homepage response revealed 2 technology item(s).
Why it matters
Response headers, page content, and other public clues suggest which technologies the service uses. These observations help explain the attack surface, but they can be incomplete or mistaken and do not by themselves confirm a vulnerability.
Evidence and check scope
Technologies found:
2
Detection method:
Website response analysis
Passive WAF, CDN, or edge signalsSoftware vulnerabilitiesInformation
Check result
Passive response signals identified one or more WAF, CDN, or edge products; enforcement was not tested.
Why it matters
This check looks for bounded passive signals of a Web Application Firewall (WAF), CDN, or other edge service. A match suggests presence but does not test enforcement, and no match does not prove absence.
Observed 0 versioned product(s); 0 had exact CPE mappings and 0 completed lookup(s).
Why it matters
This shows how many detected products had reliable version information and an exact CPE identity, allowing them to be checked against CVE applicability data. A product that could not be checked must not be treated as free of known vulnerabilities.
Evidence and check scope
Complete:
Yes
Software items found:
0
Products ready for matching:
0
Passed or not applicable (37)
Certificate matches the websiteHTTPS and encryption
Check result
The certificate matches the requested target.
Why it matters
The certificate must list the exact hostname visitors requested in its Subject Alternative Names (SAN). A mismatch produces browser warnings because the certificate may belong to a different service.
Evidence and check scope
Assessed domain:
www.plb.ucdavis.edu
Certificate domain names:
plb.ucdavis.edu, *.plb.ucdavis.edu
Host requested:
www.plb.ucdavis.edu
Resolved IPs tested:
104.18.24.9
IP that returned the observed result:
104.18.24.9
Browser-trusted certificateHTTPS and encryption
Check result
The certificate chains to a trusted root in the scanner's trust store.
Why it matters
Browsers trust a website only when its certificate can be traced to a recognized certificate provider. An untrusted certificate causes warnings and prevents visitors from reliably confirming the website's identity.
Evidence and check scope
Certificate issuer:
CN=WE1,O=Google Trust Services,C=US
Host requested:
www.plb.ucdavis.edu
Resolved IPs tested:
104.18.24.9
IP that returned the observed result:
104.18.24.9
HTTPS/TLS endpoint reachabilityHTTPS and encryption
Check result
A TLS handshake succeeded with one tested resolved endpoint on port 443.
Why it matters
This check only confirms whether a TLS handshake can be established with at least one tested resolved endpoint on the HTTPS port. Certificate trust, hostname identity, validity, chain, protocol, and cryptographic strength are evaluated separately.
Evidence and check scope
Connection established:
Yes
IP address:
104.18.24.9
Version:
TLS 1.3
Encryption suite:
TLS AES 128 GCM SHA256
Host requested:
Public DNS recordsDomain and DNS
Check result
The target resolved to 4 public IP address(es).
Why it matters
Public DNS connects the domain to its Internet addresses. Missing or incorrect records can make the service unreachable or send traffic to the wrong system.
No exact product version was observed, so there was no reliable CVE candidate to compare with the CISA Known Exploited Vulnerabilities catalog. This check is not applicable.
Why it matters
This check asks whether an applicable CVE candidate also appears in the CISA Known Exploited Vulnerabilities (KEV) catalog. A positive match means attackers have used that vulnerability in real incidents and warrants urgent investigation, but the installed software still needs to be confirmed as affected.
Evidence and check scope
Known exploited vulnerabilities:
0
Total known-exploited candidates:
0
Total possible vulnerabilities:
Public management service exposurePublic infrastructure
Check result
No public management service was found on the scanned TCP port set.
Why it matters
Remote administration services such as RDP, VNC, Docker, Kubernetes, and management consoles are high-value targets. Public exposure allows anyone on the Internet to attempt passwords or exploit an unpatched service.
Evidence and check scope
Complete:
Yes
Ports checked:
21, 22, 23, 25, 53, 80, 110, 111, 139, 143… and 48 more
Services selected for identification:
8
Services identified:
8
Database or cache exposed to the InternetPublic infrastructure
Check result
No public datastore service was found on the scanned TCP port set.
Why it matters
Databases and caches often contain sensitive information and are normally used only by internal applications. Direct Internet access makes password attacks and configuration mistakes much more likely to become a data breach.
Evidence and check scope
Complete:
Yes
Ports checked:
21, 22, 23, 25, 53, 80, 110, 111, 139, 143… and 48 more
Services selected for identification:
8
Services identified:
8
File-sharing service exposed to the InternetPublic infrastructure
Check result
No public file-sharing service was found on the scanned TCP port set.
Why it matters
Services such as SMB, NFS, and rsync can reveal or modify shared files and have a history of serious vulnerabilities. They rarely need to accept connections directly from the public Internet.
Evidence and check scope
Complete:
Yes
Ports checked:
21, 22, 23, 25, 53, 80, 110, 111, 139, 143… and 48 more
Services selected for identification:
8
Services identified:
8
Unencrypted legacy servicePublic infrastructure
Check result
No public legacy cleartext service was found on the scanned TCP port set.
Why it matters
Older services such as Telnet, FTP, and unencrypted mail or directory protocols can send passwords and data in readable form. Anyone able to observe the network path may capture them.
Evidence and check scope
Complete:
Yes
Ports checked:
21, 22, 23, 25, 53, 80, 110, 111, 139, 143… and 48 more
Services selected for identification:
8
Services identified:
8
Service identification complete:
Cross-site access rules (CORS)Website protection
Check result
The root-response probe did not reflect the arbitrary test origin or combine a wildcard origin with credentials.
Why it matters
Cross-Origin Resource Sharing (CORS) decides which websites may read responses from this service in a visitor's browser. Rules that trust arbitrary origins, especially with login cookies, can expose private data to another website.
Scope of this check
This check only evaluates the homepage response and content that the scanner could reach. Other pages and sign-in flows may use different settings.
Evidence and check scope
Arbitrary origin accepted:
No
Allows all origins:
No
Credentials allowed:
No
Certificate expiry and validityHTTPS and encryption
Check result
The certificate is currently valid and expires at 2026-10-26T01:13:25Z.
Why it matters
A certificate works only between its start and expiry dates. An expired, not-yet-valid, or soon-to-expire certificate can trigger browser warnings and interrupt access to the website or API.
Evidence and check scope
Valid from:
Expires at:
Days remaining:
34.9
Host requested:
www.plb.ucdavis.edu
Resolved IPs tested:
Certificate key and signature strengthHTTPS and encryption
Check result
The certificate uses ECDSA-SHA256 with a 256-bit public key.
Why it matters
The certificate's public key and signature algorithm protect it from forgery. Keys that are too short or signatures based on obsolete algorithms provide less protection against modern attacks.
Evidence and check scope
Signature algorithm:
ECDSA-SHA256
Public-key algorithm:
ECDSA
Public-key size:
256
Host requested:
www.plb.ucdavis.edu
Resolved IPs tested:
Supported TLS versionsHTTPS and encryption
Check result
TLS 1.0 and TLS 1.1 were conclusively rejected, while at least one modern TLS version was accepted on the tested endpoint.
Why it matters
TLS 1.0 and TLS 1.1 use outdated security designs and are no longer accepted by modern standards. Leaving them enabled allows older, weaker connection methods.
No independent abuse-list consensus was found across 5 definitive providers.
Why it matters
Security and email providers maintain DNS-based blacklists of IP addresses associated with spam, malware, or compromised systems. Several current, independent listings are a strong reason to investigate, although a shared IP can sometimes affect unrelated customers.
Evidence and check scope
IPv4 addresses checked:
2
Blocklists reporting an issue:
0
Blocklists with no match:
5
Blocklists unavailable:
1
Blocklists checked conclusively:
Email spoofing protection (DMARC)Email protection
Check result
A DMARC record was found for the registrable email domain.
Why it matters
DMARC lets the domain owner tell receiving services what to do when the visible From address is not verified by SPF or DKIM. Without DMARC, attackers have more opportunity to impersonate the domain in phishing email.
The bounded core DMARC tags passed structural validation.
Why it matters
This bounded check validates the core structure and required tags of the DMARC record found by the domain-tree lookup. It does not verify delivery or authorization of every external reporting destination.
Session cookies protected from scripts (HttpOnly)Website protectionNot applicable
Check result
No cookie name on the inspected root response matched the bounded session-cookie heuristic; HttpOnly risk was not scored.
Why it matters
HttpOnly prevents browser scripts from directly reading a cookie. It does not fix script injection, but it makes theft of session and authentication cookies more difficult.
Scope of this check
This check only evaluates the homepage response and content that the scanner could reach. Other pages and sign-in flows may use different settings.
Evidence and check scope
Total:
1
Session-related cookies:
0
Cookies sent only over HTTPS (Secure)Website protectionNot applicable
Check result
Cookies were observed on the inspected root response, but no cookie name matched the bounded session-cookie heuristic; Secure risk was not scored.
Why it matters
The Secure attribute prevents a browser from sending a cookie over unencrypted HTTP. This bounded check scores cookies whose names look session- or authentication-related; other cookies are reported as context but do not by themselves prove that sensitive data is exposed.
Scope of this check
This check only evaluates the homepage response and content that the scanner could reach. Other pages and sign-in flows may use different settings.
Evidence and check scope
Total:
1
Cookies using Secure:
Potential CVEs for observed versionsSoftware vulnerabilitiesNot applicable
Check result
The scan completed without observing an exact product version that could be matched reliably to CVE records. This check is not applicable; it does not mean the system is free of vulnerabilities.
Why it matters
This check compares an observed product only when a reliable version and exact CPE identity are available, using applicability records from the National Vulnerability Database (NVD). Any returned match is a lead, not confirmation: the installed software may include vendor fixes or differ from the version visible on the Internet.
Every cookie observed on the inspected root response has an explicit SameSite value, and none uses SameSite=None without Secure.
Why it matters
SameSite limits when a browser includes cookies in requests started by another website. This helps prevent another site from silently making an authenticated request on a user's behalf.
Scope of this check
This check only evaluates the homepage response and content that the scanner could reach. Other pages and sign-in flows may use different settings.
Evidence and check scope
Total:
1
Cookies missing SameSite:
0
SameSite=None cookies missing Secure:
0
Protection from deceptive framing (clickjacking)Website protection
Check result
The inspected root HTML response restricts framing with X-Frame-Options.
Why it matters
Another website can place this page inside a hidden or misleading frame and trick a user into clicking an unintended action. Frame restrictions tell browsers which sites, if any, may embed the page.
Scope of this check
This check only evaluates the homepage response and content that the scanner could reach. Other pages and sign-in flows may use different settings.
Evidence and check scope
Protection method:
X Frame Options
Observed value:
SAMEORIGIN
Response inspected:
Homepage HTML response
Insecure content on an HTTPS pageWebsite protection
Check result
No active HTTP resource or form destination was found in the inspected root HTTPS page.
Why it matters
An HTTPS page can still load scripts, frames, styles, or forms over unencrypted HTTP. An attacker on the network may alter that content and compromise the otherwise secure page.
Scope of this check
This check only evaluates the homepage response and content that the scanner could reach. Other pages and sign-in flows may use different settings.
The inspected root response sets X-Content-Type-Options: nosniff.
Why it matters
Without the nosniff setting, a browser may guess a file's type and treat harmless-looking content as executable code. This can turn an incorrect Content-Type into a security issue.
Scope of this check
This check only evaluates the homepage response and content that the scanner could reach. Other pages and sign-in flows may use different settings.
Evidence and check scope
Observed value:
nosniff
Response inspected:
Homepage response headers
Host requested:
www.plb.ucdavis.edu
Host observed:
Complete certificate chainHTTPS and encryption
Check result
The server presented 3 certificate(s).
Why it matters
The server must provide the intermediate certificates that connect its website certificate to a trusted provider. If any are missing, some browsers, mobile devices, or API clients may reject the connection.
Evidence and check scope
Certificates in the chain:
3
Host requested:
www.plb.ucdavis.edu
Resolved IPs tested:
104.18.24.9
IP that returned the observed result:
104.18.24.9
Automatic redirect to HTTPSHTTPS and encryption
Check result
The HTTP root redirects to HTTPS within the target domain.
Why it matters
Visitors may enter an address beginning with HTTP or follow an old link. Redirecting them immediately to HTTPS prevents the rest of the visit from continuing over an unencrypted connection.
Scope of this check
This check only evaluates the homepage response and content that the scanner could reach. Other pages and sign-in flows may use different settings.
Evidence and check scope
Website reachable:
Yes
Redirects followed:
1
Final connection:
https
Direct HTTPS redirect:
Public directory listingSoftware vulnerabilities
Check result
The root page did not match a common automatic directory-index pattern.
Why it matters
When a web server automatically lists a directory, visitors may discover files that were never linked publicly, including backups, logs, or deployment artifacts.
Scope of this check
This check only evaluates the homepage response and content that the scanner could reach. Other pages and sign-in flows may use different settings.
Evidence and check scope
Homepage only:
Yes
Directory listing pattern found:
No
Host requested:
www.plb.ucdavis.edu
Host observed:
Authorized email senders (SPF)Email protection
Check result
An SPF record was found for the registrable email domain.
Why it matters
Sender Policy Framework (SPF) lists the systems allowed to send email for the domain. Without it, receiving services have less evidence to distinguish legitimate mail from spoofed mail.
This bounded check validates the published SPF record's basic structure, duplicate-record rule, and directly declared DNS-lookup terms. It does not recursively expand every include or redirect, so a pass is not a complete SPF evaluation.
All 1 explicit MX target(s) resolved to public addresses.
Why it matters
MX records direct incoming email to the correct mail servers. Broken records can stop delivery, while a Null MX clearly tells senders that the domain does not receive email.
Evidence and check scope
Mail servers:
ucdavis-edu.mail.protection.outlook.com (10)
Does not receive email:
No
Null MX mixed with mail routes:
No
Policy domain:
ucdavis.edu
URL privacy (Referrer-Policy)Website protection
Check result
The inspected root HTML response sets an explicit privacy-preserving Referrer-Policy.
Why it matters
When a visitor follows a link, the browser may send information about the previous URL to the destination. Modern browsers default to strict-origin-when-cross-origin when no header is sent, so an absent header is a hardening gap rather than proof that a full sensitive URL was exposed.
Scope of this check
This check only evaluates the homepage response and content that the scanner could reach. Other pages and sign-in flows may use different settings.
Evidence and check scope
Policy:
same-origin
Response inspected:
Homepage HTML response
Host requested:
www.plb.ucdavis.edu
Exposed software versionSoftware vulnerabilities
Check result
No recognizable software version token was found in the bounded headers or page metadata of the inspected root response.
Why it matters
Exact web server or framework versions help attackers quickly look for known weaknesses that may apply. Hiding a version is not a substitute for patching, but unnecessary disclosure gives away useful targeting information.
Scope of this check
This check only evaluates the homepage response and content that the scanner could reach. Other pages and sign-in flows may use different settings.
Evidence and check scope
Host requested:
www.plb.ucdavis.edu
Host observed:
www.plb.ucdavis.edu
DMARC aggregate-report URIEmail protection
Check result
A syntactically valid aggregate-report mailto URI is published; external authorization and delivery were not verified.
Why it matters
This check looks for at least one syntactically usable mailto destination in rua; a passing result confirms that publication. It does not verify authorization for an external destination or prove that reports can actually be delivered and monitored.
Evidence and check scope
Configured:
Yes
Report destination type:
mailto
External report authorization verified:
No
Report delivery verified:
No
Email receiving configurationEmail protection
Check result
The domain publishes 1 explicit MX route(s), declaring that it receives email.
Why it matters
This check asks whether the domain clearly declares email-receiving intent through one or more explicit MX routes or a sole Null MX. MX target validity and reachability are evaluated separately by the mail-route health check.
Evidence and check scope
Mail servers:
ucdavis-edu.mail.protection.outlook.com (10)
Does not receive email:
No
Null MX mixed with mail routes:
No
Policy domain:
ucdavis.edu
Allowed certificate issuers (CAA)Domain and DNS
Check result
Found 9 valid CAA issue rule(s) and 0 issuewild rule(s); no malformed or unknown critical rule was observed.
Why it matters
Certificate Authority Authorization (CAA) records state which certificate providers may issue certificates for the domain. This reduces the chance of an unintended provider issuing one.
This check counts the authoritative name-server hostnames published for the domain. Fewer than two creates an obvious single-server dependency; two or more meets the count baseline but does not prove that the servers use independent networks or remain available during an outage.
HSTS protection periodHTTPS and encryptionNot applicable
Check result
HSTS policy strength was not assessed because the inspected root response has no effective HSTS policy.
Why it matters
The max-age value controls how long browsers remember to use HTTPS. A very short period provides limited protection, while includeSubDomains also covers every subdomain and can break one that does not support HTTPS.
Scope of this check
This check only evaluates the homepage response and content that the scanner could reach. Other pages and sign-in flows may use different settings.
Evidence and check scope
Required condition:
Effective HSTS policy
Response inspected:
Have @ucdavis.edu email addresses appeared in exposed data or information-stealer (infostealer) logs?
There are currently 1,352 exposed email records matching the ucdavis.edu domain. These records may be old or already resolved. The website owner should verify them before resetting passwords or locking related accounts.
Which public IPs, services, and ports does www.plb.ucdavis.edu expose?
The assessment observed 4 public IPs and 8 open ports for www.plb.ucdavis.edu; the infrastructure appears to be operated by Cloudflare, Inc.. An open port is not automatically a vulnerability, but every public service should be updated and appropriately restricted.
How many subdomains of ucdavis.edu have been discovered?
The assessment observed 1,363+ public subdomains of ucdavis.edu. This list can reveal additional entry points such as APIs, administration systems, or test environments, but it does not mean that every subdomain is risky.
Infostealer intelligence may contain credentials associated with the domain, but it does not prove that an account is current, valid, or still exposed.
What to do
Review the masked evidence and observation time, validate affected accounts and devices, then reset active credentials and sessions, enforce MFA, and remove malware where confirmed.
Evidence and check scope
How exposed email records are matched:
Only email addresses whose domain exactly matches this website
Collection refresh status:
completed
Matching exposed email records:
1,352
The actual record count may be higher:
No
Estimated infostealer-infected devices:
151
Device count is estimated:
Yes
How to interpret this evidence:
Matched records contain an email address whose domain exactly matches the assessed website's registrable domain. Credential records are intelligence observations, not proof that an account is still active. Estimated victim devices are infostealer infection devices associated with matched records; they are not evidence that those devices are owned or operated by the assessed organization.
Evidence samples available:
Yes
Evidence samples shown:
5
Evidence sample limit:
10
8 additional evidence fields are not shown here.
What to do
Allow each sensitive browser feature only for the pages and trusted origins that require it, and disable the rest.
Scope of this check
This check only evaluates the homepage response and content that the scanner could reach. Other pages and sign-in flows may use different settings.
Industry
Updated at 
United States
