Definition
A web asset is a website, web application or API that an organisation runs and that can be reached over the web. It is identified by its URL or domain and is part of the external attack surface.
What a web asset is
In security, a web asset is anything an organisation runs that can be reached over the web: a website, a web application, a customer portal or an API. Each one is identified by its URL or domain, and each one is part of the organisation's external attack surface.
In web development, "web assets" can also mean the static files a site loads, such as images, stylesheets and scripts. This article uses the security meaning: the applications and APIs an attacker could target, and that a penetration test can cover.
Types of web assets
- Websites and web applications: marketing sites, customer portals, admin panels, online shops and internal tools exposed to the internet
- APIs: REST or GraphQL endpoints used by mobile apps, partners or the organisation's own front end, usually identified by a base URL
- Subdomains and environments: separate copies of an application for staging, testing or user acceptance testing, which are often less protected than production
Web assets vs infrastructure assets
| Web asset | Infrastructure asset | |
|---|---|---|
| What it is | A website, web application or API | A host or network address |
| Identified by | URL or domain | IP address or range |
| Typical weaknesses | Broken access control, injection, authentication flaws, exposed data in APIs | Open ports, unpatched services, weak remote access |
| Typical testing | Web application and API penetration testing | Network and infrastructure penetration testing |
The two are closely linked: a web application runs on infrastructure, and an attacker often moves from one to the other along an attack path.
Why a web asset inventory matters
You cannot test or protect what you do not know about. Organisations regularly lose track of web assets:
- Forgotten applications: old campaign sites, retired portals and test systems that were never switched off
- Staging and test environments: copies of production with weaker passwords, debug features or real data
- Undocumented APIs: endpoints added for a mobile app or partner and never reviewed
- Shadow IT: sites and tools set up by teams without security being involved
A complete, up-to-date inventory of web assets is the starting point for attack surface management, vulnerability management and penetration testing.
How web assets are discovered
Most organisations combine several sources to build their list:
- Internal records: asset registers, a CMDB and the teams that build and run applications
- DNS: the organisation's domains and subdomains, which often reveal forgotten sites
- Certificate transparency logs: public records of TLS certificates, which list hostnames as soon as a certificate is issued
- Cloud accounts: load balancers, storage buckets, serverless functions and API gateways that expose web endpoints
- Third parties: SaaS tools, agencies and partners that host sites or APIs on the organisation's behalf
Discovery is never finished. New applications, environments and APIs appear all the time, so the inventory needs regular review.
What to record for each web asset
- URL or domain: written consistently, so the same asset is not listed twice
- Type: web application or API
- Owner: the team responsible for it
- Environment: production, staging, testing and so on
- Business criticality: how much the business depends on it
- Data it handles: for example personal data, payment data or internal documents
- Hosting and technologies: where it runs and what it is built with
- Last tested: when it was last assessed, and how
Criticality, environment and data matter most for prioritisation: the same vulnerability is far more urgent on a critical production application that handles customer data than on a low-value test site.
Permission and ownership
A web asset should only be tested by people who have permission to test it. In practice that means two things:
- Authorisation: a written agreement that defines what may be tested, when and how. For assets hosted by a third party, such as a SaaS platform or cloud provider, their testing rules apply as well.
- Proof of control: a technical check that the organisation actually controls the domain or site. Common methods are a DNS TXT record, a meta tag in the page's head, a specific HTTP header or a verification file at a fixed URL, the same kinds of checks search engines and certificate authorities use.
Together they prevent testing someone else's system by mistake and stop testing tools from being pointed at targets without permission.
How web assets are tested
- Automated scanning: dynamic application security testing (DAST) tools crawl an application and look for known classes of weakness
- Penetration testing: testers, or AI agents working within agreed limits, attack the application the way a real attacker would and confirm what can actually be exploited
- API testing: focuses on authentication, authorisation and data exposure in each endpoint, guided by the OWASP API Security Top 10
- Continuous testing: because web assets change with every release, many organisations move from yearly tests to continuous penetration testing
The OWASP Top 10 is the most widely used reference for the kinds of weaknesses web applications are tested for, such as broken access control and injection.
How Plainsea helps
Plainsea tests web applications and APIs the way a real attacker would, within the scope you set, and confirms every finding before it reaches your team.