> For the complete documentation index, see [llms.txt](https://cortex-docs.paloaltonetworks.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://cortex-docs.paloaltonetworks.com/cortex-xsiam/detect-investigate-and-respond-to-threats/asset-management/asset-classes/external-surface-assets/website-assets.md).
# Website assets
Cortex XSIAM websites data extends Attack Surface Management (ASM) protection by identifying insecure websites, web components, and technologies running on your managed and unmanaged web assets. Cortex XSIAM scans your public-facing websites, creating a continuously updated inventory of your web assets, including the server software and other technologies powering your web applications.
Websites data in Cortex XSIAM enables you to accomplish the following:
* Develop a single source of truth for all of your organization's web inventory
* Track and monitor your risk due to third-party libraries
* Continuously discover and monitor external web application inventory and third-party technologies
* Identify insecure and misconfigured websites, vulnerable technologies, and dependencies
* Improve security ratings by identifying sites failing security best practices
**The difference between websites and external services**
In Cortex XSIAM, external services are public-facing network services; for example, an RDP server or an HTTP server. Websites represent the content and the software stack that was used to generate the website.
An HTTP service represents a single HTTP server (on-prem) or a cohesive group of HTTP servers (cloud). A website can be served by a single HTTP server or by multiple HTTP servers. Some of these HTTP servers could be hosted by a cloud provider, others on-prem. Generally, the relationship between HTTP services and websites can be described as follows:
* A website is supported by one or more HTTP services.
* A cloud HTTP service serves a single website.
* An on-prem HTTP service serves multiple websites, potentially hundreds.
**The difference between websites and domains**
A domain is simply the registration of a domain (for example, your organization might own [www.example.com](http://www.example.com)). You can have a domain without a website behind it. You can also have a domain that does not resolve to an IP address (which means it does not have a website behind it). Cortex XSIAM includes websites with a domain name or an IP address.
**Websites field descriptions**
The Websites page lists your websites in a table format that can be sorted, filtered, and downloaded. Some of the key fields are described in the table below.
| Field | Description |
| ----------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| Authentication | Detected authentication method. Results could be none, form based authentication (e.g. user ID and password), or a single-sign on method. |
| Attributed Organizations | Business unit this website is associated with. |
| Externally Detected Providers | Hosting provider. |
| Website Failed Security Assessments | Which of the security best practices the website failed. |
| First Crawled Timestamp | When the website was first observed. |
| Host | Domain or IP of the website host.
- A closed lock indicates HTTPS.
- An open lock indicates HTTP.
|
| HTTP Type | HTTPS, HTTP redirecting to HTTPS, or HTTP. |
| IP Addresses | IP addresses associated with this website. |
| Is Active | Yes — Indicates the website is active, which means it has been observed recently.
No — Indicates the website is inactive, which means Cortex Xpanse no longer sees it on the internet or it is no longer attributed to your organization.
|
| Last Crawled Timestamp | When the website was most recently observed in a Cortex Xpanse scan. |
| Port | Port for the website. |
| Site Category | The inferred business purpose of the website based on the technologies used on that website. Full list of site categories is Ecommerce, Advertising, Affiliate Programs, Appointment scheduling, Blogs, CMS, CRM, Development, Documentation, Issue Tracker, LMS, Reservations & Delivery, Recruitment & Staffing.
If a technology doesn't fit into one of the listed categories, this field will be blank.
|
| Website Technologies | Any technologies detected on the website. |
| Website Third Party Script Domains | Third-party domains that serve the scripts (not the scripts themselves). |
| Website ID | Unique ID associated with the website. |
**Website details**
Click a row in the Websites table to open the details page for that website. The following sections describe the information on the website details page.
**Site Details, Site Categories, Site Deployment Details**
Summarizes key information about the security of the website.
**Most Recent Screenshot**
A screenshot and link to the website to make it easier to investigate issues. If you don't see a screen shot, the website may have been down when we scanned the page or that access was blocked for our scanner (in which case you probably won't see any technologies listed under Technologies Used either). If the screenshot is incomplete (a blank or invalid layout), the page may have loaded too slowly—we take the screenshot six seconds after we request the page.
**Security Best Practices Analysis**
Provides an at-a-glance look at whether the website is following broadly accepted security best practices.
We perform only the relevant security best practice assessments on each website. For example, if a website redirects somewhere else, many of the security assessments are performed on the website the user is redirected to; only the Has HTTPS Enabled and Protocol Downgrade assessments are performed on the original website. And some security assessments don’t make sense on non-HTTPS websites (e.g. mixed content and HSTS header), so those assessments are not performed.
Some security best practice assessments are performed only on webpages without "transient errors". We consider a page to have a transient error if the HTTP status code is 405, 407, 408, 409 or greater than 411. In this case, we assume this is not a normal condition of the website and visiting the page later or in different conditions would yield a different result.
If we have no matching observation for an assessment, the assessment will not be displayed. For example, if has a single page with a 404 status code, the Mixed Content assessment would be performed (404 is not a transient error) but the X-Frame-Options assessment would not be.
The table below lists each of the security best practices, which websites and webpages the analysis is performed on, and the criteria we use to determine whether the website Passes or Fails the assessment.
| Website Security Best Practice | Performed on these websites | Performed on these pages | Pass/Fail Criteria |
| ------------------------------------------ | ------------------------------------------ | ------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Has HTTPS Enabled | All websites | All | Passes if the website is accessed over TLS or redirects to an HTTPS website. |
| Secure Forms | HTTPS websites that do not always redirect | Pages without transient errors | Fails if we find an HTML form with an action to an insecure website. This applies only to static forms and will not detect dynamically rendered forms. |
| No Mixed Content | HTTPS websites that do not always redirect | Pages without transient errors | Fails if we find a page that is using a resource (image, stylesheet, script but not just a \ link) loaded over HTTP. |
| Protocol Downgrade | All websites | All | Fails if we find a transition from HTTPS to HTTP in the redirect chain. |
| Sets Valid X-Frame-Options Header | Websites that do not always redirect | Pages with 2xx status code | Fails if:
- X-Frame-Options header is not empty and is neither DENY or SAMEORIGIN
- Content-Security-Policy header is not set or syntactically invalid
|
| Sets Valid X-Content-Type-Options Header | Websites that do not always redirect | Pages with 2xx status code | Fails if X-Content-Type-Options is not set or not “nosniff” |
| Sets valid Content-Type Header | Websites that do not always redirect | Pages with 2xx status code | Fails if Content-Type is not set or set to an invalid value. |
| Sets HTTP Strict Transport-Security-Header | HTTPS websites that do not always redirect | Pages without transient errors | Fails if there is no “Strict-Transport-Security” header. |
| Sets valid Referrer-Policy Header | Websites that do not always redirect | Pages without transient errors | Fails if Referrer-Policy header not set or set to an invalid value. |
**Technologies Used**
List of the technologies used on your website.
**HTML Form Analysis**
List of login forms. Login forms are only detected in a static environment, so if the form is created by JavaScript, it will not be detected. Only login forms are displayed in analysis.
**Domain Details**
Information about the website domain, including a link to the domain in the Inventory.
**Third Party Resources**
List of the scripts and CSS loaded from domains that are not owned by your organization.
**Other Websites Hosted with This Website**
List of other websites owned by your organization and hosted on the same IP addresses.
**Services Hosting This Website**
List of services hosting the website in the last 30 days.
**GeoMap**
Map indicating the IP region of the website.
**Externally Inferred CVEs**
Externally inferred CVEs associated with the technologies used on your website.
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:
```
GET https://cortex-docs.paloaltonetworks.com/cortex-xsiam/detect-investigate-and-respond-to-threats/asset-management/asset-classes/external-surface-assets/website-assets.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.