Shared Hosting Security: How Safe Is It Really?

The Shared Hosting Security Reality: What the Multi-Tenant Model Means for Your Website

Shared hosting powers a significant portion of the web. It is the entry point for first-time website owners, the budget-friendly option for personal projects, and the default choice for small businesses that do not want to manage server infrastructure. But the very architecture that makes shared hosting affordable — placing hundreds or thousands of websites on a single physical server — introduces security considerations that are fundamentally different from isolated hosting environments. Shared hosting security is not an oxymoron, and properly configured shared hosting can be acceptably secure for the majority of websites. But understanding exactly what risks exist, what protections modern hosts deploy, and where your own responsibility as a site owner begins is essential for making informed decisions about whether shared hosting is appropriate for your website and what steps you must take to protect it.

This guide examines shared hosting security from multiple angles: the architectural vulnerabilities inherent in multi-tenant environments, the isolation technologies that providers use to mitigate those vulnerabilities, the real-world threat landscape that shared hosting sites face, the security responsibilities that fall on you versus your hosting provider, and the specific configuration and monitoring practices that significantly reduce your risk. At Hosting Captain, we believe that security should never be a premium add-on or an afterthought — it should be transparently built into every plan — and we evaluate every hosting provider in our comparisons through this lens. For the foundational understanding of how shared hosting operates and what resources it allocates, our complete beginner's guide to shared hosting provides the architectural context that makes the security discussion here more concrete. The Mozilla guide to web servers also offers a helpful technical primer on how web servers handle requests, which is directly relevant to understanding the attack surface we discuss throughout.

The Multi-Tenant Security Problem: What You Share and What You Risk

Cross-Account Contamination: The Core Concern

The fundamental security question in shared hosting is whether a vulnerability in one website on a server can be leveraged to compromise other websites on the same server. This concern is not theoretical. In a shared hosting environment, all accounts on a server share the same operating system kernel, the same physical memory, the same storage subsystem, and often the same web server and database server processes. If the isolation between accounts is weak or misconfigured, a malicious actor who compromises one site could potentially read files from neighboring accounts, access their databases, intercept their traffic, or use the compromised account as a launching point for attacks against other tenants. The history of shared hosting includes documented cases where precisely this occurred — a WordPress plugin vulnerability on one site was exploited to plant malware that spread laterally to dozens of other sites on the same server, or a file upload form with insufficient validation allowed an attacker to write a PHP shell into a directory that was readable by other accounts due to overly permissive file permissions.

The severity of cross-account contamination risk depends entirely on the isolation architecture the hosting provider has deployed. In the worst case — an older hosting platform running a bare Apache with mod_php where all PHP scripts execute as a shared system user like nobody or www-data — every account's files and processes are effectively accessible to every other account. This configuration, which was common in shared hosting a decade ago, is now rare among reputable providers but still exists on some budget and legacy hosting platforms. In the best case — a modern hosting platform running CloudLinux with CageFS, PHP-FPM pools under per-user UIDs, and kernel-level resource isolation — each account is contained in a virtualized filesystem that prevents it from seeing, reading, or interacting with other accounts' data, processes, or network connections. The difference between these two extremes is the difference between a shared hosting environment where security is a genuine concern requiring active vigilance and one where the isolation is strong enough that the residual risk is comparable to other hosting models.

The Noisy Neighbor Problem Extends to Security

Beyond active attacks, shared hosting creates a passive security risk through the noisy neighbor phenomenon. When hundreds of websites share a single server, the collective attack surface is the sum of every site's vulnerabilities, not just your own. Even if your website is perfectly maintained — every plugin updated, every password strong, every file permission correctly set — your site can be affected when a neighboring site is compromised. A distributed denial-of-service attack targeting another tenant on your server consumes shared bandwidth and server resources that degrade your site's availability. A spam campaign launched from a compromised email account on your shared server poisons the server's IP reputation, causing your legitimate transactional emails to land in spam folders. A brute-force attack against another site's WordPress login page saturates the server's PHP-FPM pool, causing your site to return 503 errors to visitors. In each case, your site's security posture did not fail, but you experienced the consequences of someone else's failure anyway — and that is the structural reality of multi-tenant hosting.

This passive risk is why the quality of your hosting provider's abuse handling and tenant monitoring directly affects your security. Providers that actively monitor for compromised accounts, that respond rapidly to abuse reports, that automatically suspend accounts exhibiting malicious behavior, and that maintain IP reputation monitoring across their infrastructure provide meaningful protection against the downstream effects of other tenants' security failures. Providers that take a hands-off approach, only responding to abuse when formally notified and taking days to act, expose every tenant on the server to extended periods of degraded service due to a neighbor's compromise. When evaluating shared hosting providers at Hosting Captain, we investigate their abuse response processes, their automated security monitoring infrastructure, and their historical track record on IP reputation management — factors that do not appear on pricing comparison pages but that directly affect your site's reliability and deliverability.

Isolation Technologies That Make Shared Hosting Secure

CloudLinux and CageFS: The Kernel-Level Isolation Layer

CloudLinux OS, deployed on a large percentage of commercial shared hosting servers in 2026, is the technology most responsible for making shared hosting acceptably secure. CloudLinux extends the Linux kernel with a module called LVE (Lightweight Virtual Environment) that wraps each hosting account in a resource container with hard limits on CPU, memory, concurrent connections, disk I/O, and the number of processes that can run simultaneously. Critically, CloudLinux also includes CageFS — a virtualized file system that encapsulates each user, preventing them from seeing any files, directories, or processes outside their own account. When CageFS is active, an attacker who compromises a WordPress site on one account cannot use the ls command to list other accounts' directories, cannot read /etc/passwd to enumerate users, cannot access /proc to inspect other tenants' running processes, and cannot see or interact with the server's system binaries in a way that could facilitate privilege escalation.

CageFS and LVE together create what is effectively a container-like isolation environment within a shared operating system, without the overhead of running a separate kernel for each tenant as a full VPS would require. The isolation is not as complete as a VPS — a kernel-level vulnerability could theoretically break out of CageFS, whereas it would need to break out of both the guest kernel and the hypervisor on a KVM-based VPS — but for the threat models that shared hosting sites realistically face, CloudLinux with CageFS provides isolation that is sufficient to prevent the most common lateral movement and cross-account compromise scenarios. Hosting Captain considers CloudLinux with CageFS to be the minimum acceptable isolation standard for any shared hosting provider we recommend, and we treat the absence of this technology (or an equivalent like Virtuozzo with similar isolation guarantees) as a disqualifying factor in our evaluations.

PHP Execution Isolation: suPHP, FastCGI, and PHP-FPM

How PHP scripts execute on a shared hosting server is as important as the filesystem isolation, because PHP is the execution environment for the overwhelming majority of compromised websites. In older shared hosting configurations, all PHP scripts ran under a single system user — typically nobody or www-data — meaning that every account's scripts executed with identical permissions, and a PHP script in one account could read, write, or execute files belonging to any other account. Modern providers use one of three mechanisms to ensure that PHP scripts execute under each account's own Linux user: suPHP executes PHP via CGI under the account owner's UID; FastCGI with suexec uses a setuid wrapper to spawn PHP processes with the correct user permissions; and PHP-FPM pools are configured per-account with each pool running under the respective account's user. All three approaches ensure that a PHP script compromised through a plugin vulnerability or file upload exploit can only access files and directories owned by that specific account, containing the blast radius of the compromise to a single tenant rather than allowing it to spread server-wide.

Beyond user-level execution isolation, PHP configuration hardening at the server level closes common attack vectors. The disable_functions directive is used to block PHP functions that are commonly exploited for command execution and lateral movement: exec, system, passthru, shell_exec, popen, proc_open, and similar functions are disabled by default, preventing a compromised script from executing arbitrary shell commands. The open_basedir directive restricts PHP file operations to the account's designated directory tree, preventing scripts from reading or including files from outside the account's document root. ModSecurity or an equivalent web application firewall is deployed as an Apache or Nginx module to inspect incoming HTTP requests for common attack patterns — SQL injection, cross-site scripting, local file inclusion, remote file inclusion — and block malicious requests before they reach the PHP interpreter. At Hosting Captain, these PHP hardening measures are standard configuration on every shared hosting server, applied uniformly across all accounts without requiring individual site owners to implement them.

The Threat Landscape: What Actually Attacks Shared Hosting Sites

Automated Vulnerability Scanning and Mass Exploitation

The most common security threat to shared hosting websites is not a targeted attacker specifically interested in your site, but rather automated scanning infrastructure that probes millions of websites for known vulnerabilities and exploits them at scale. Bots continuously scan the IPv4 address space for web servers, fingerprint the software running on each discovered site (WordPress version, plugin inventory, theme identification), and cross-reference the discovered software against databases of known vulnerabilities. When a match is found, the bot attempts the exploit automatically — uploading a PHP web shell through a vulnerable file upload form, injecting malicious JavaScript through an unpatched cross-site scripting vulnerability, or extracting database credentials through a SQL injection vulnerability that the site owner has not yet patched.

The volume of these automated attacks is staggering. A typical shared hosting server receives thousands to tens of thousands of malicious probing requests per day — attempts to access /wp-admin with common passwords, scans for exposed phpMyAdmin instances, requests for backup files with predictable names like backup.zip or database.sql, and exploit attempts against known plugin vulnerabilities that were patched years ago but persist on sites that have not been updated. The majority of these attacks are blocked by server-level protections (ModSecurity rules, fail2ban, rate limiting) without the site owner ever being aware of them. But the attacks that succeed — and they do succeed on sites with outdated software, weak passwords, or misconfigured file permissions — are what lead to compromised sites serving malware to visitors, sending spam through the hosting server's mail infrastructure, or being used as part of a botnet for DDoS attacks against other targets.

Brute Force Attacks on Login Pages

Brute force attacks targeting content management system login pages — overwhelmingly WordPress's wp-login.php — represent one of the highest-volume threats that shared hosting sites face. An attacker uses a list of common usernames (admin, administrator, the site's domain name, the author's display name) and a dictionary of common or previously leaked passwords to attempt thousands of login combinations per hour against a single site. On a shared hosting server where many tenants run WordPress, a brute force campaign against multiple sites simultaneously can consume enough PHP-FPM workers and MySQL connections to degrade performance across the entire server, even for sites that are not themselves being targeted — the noisy neighbor problem manifesting as a security-induced performance incident.

Provider-level brute force protection is the most effective defense because it stops attack traffic before it reaches individual sites. Fail2ban or similar intrusion prevention tools monitor authentication logs across the server and automatically block IP addresses that generate excessive failed login attempts across any account. Some providers implement rate limiting at the web server or network firewall level, restricting the number of POST requests to wp-login.php from a single IP address within a given time window. Two-factor authentication for hosting control panel access — cPanel, DirectAdmin, or the provider's proprietary panel — protects the account management interface from credential-stuffing attacks that would allow an attacker to modify DNS records, create email forwarders, or access the file manager and database tools. Site owners bear the responsibility for securing their own CMS login pages — using strong unique passwords, implementing two-factor authentication via a WordPress plugin, changing the default admin username, and limiting login attempts with a security plugin — but the provider's server-level protections serve as an essential first line of defense that reduces the attack volume reaching individual sites. For a deeper understanding of the resource constraints that affect security tooling, our guide on shared hosting resource limits for CPU, RAM, and inodes explains how server resources are partitioned — and how security monitoring fits within those allocations.

Malware Infections and Their Consequences

When a shared hosting site is compromised, the most common outcome is malware infection — the attacker injects malicious code into the site's files or database that serves a purpose other than simply defacing or taking down the site. Typical malware payloads include: SEO spam that injects hidden links and keywords into the site's pages to manipulate search engine rankings for the attacker's benefit; phishing kit deployment that uses the compromised site to host fake login pages for banks, email providers, or social media platforms; cryptojacking scripts that use visitors' browsers to mine cryptocurrency while they browse the compromised site; drive-by download scripts that attempt to exploit browser vulnerabilities to install malware on visitors' devices; and email spam scripts that use the hosting server's mail infrastructure to send bulk spam, which rapidly blacklists the server's IP address and causes legitimate email from all tenants to be rejected or filtered to spam.

The consequences for the site owner range from inconvenient to catastrophic. Google's Safe Browsing service detects malware-infected sites and displays a prominent red warning page to visitors — "The site ahead contains malware" — which effectively takes the site offline until the infection is cleaned and Google re-scans the site, a process that can take 24 to 72 hours. Email blacklists triggered by spam from a compromised account can take days or weeks to resolve, during which time business communications, order confirmations, and password reset emails fail silently. Hosting providers that detect malware on an account may suspend that account immediately to protect other tenants, taking the site completely offline until the site owner removes the malware and implements preventive measures. In severe cases, particularly with repeat infections, the provider may terminate the account entirely. The recovery process — identifying all infected files, removing malicious code, patching the vulnerability that allowed the compromise, changing all passwords, restoring from a clean backup if available, and requesting review from Google and email blacklist operators — can require days of work and hundreds of dollars in developer or security consultant fees.

What Your Shared Hosting Provider Protects Against — and What It Does Not

Provider-Responsibility Protections

On a well-configured shared hosting platform, the provider handles a substantial set of security responsibilities at the infrastructure level. Server operating system patching — applying kernel updates, library patches, and service software updates that address known vulnerabilities — is the provider's responsibility and should occur on a regular schedule, with critical security patches applied within hours of release. Web server software (Apache, Nginx, LiteSpeed) and PHP version updates are provider-managed, ensuring that the underlying execution environment is not running versions with known, exploitable vulnerabilities. Database server (MySQL, MariaDB) security configuration and patching is provider territory. Firewall configuration at the network and server level, DDoS mitigation at the data center edge, and intrusion detection monitoring of server logs for suspicious activity patterns are all provider-managed security functions.

The provider also controls the configuration of account isolation mechanisms — CageFS, PHP execution user separation, open_basedir restrictions, disabled PHP functions — that prevent cross-account compromise. The web application firewall rules that block common attack patterns at the HTTP request level are configured and maintained by the provider's security team. SSL/TLS certificate provisioning and renewal, increasingly automated via AutoSSL and Let's Encrypt integration, is a provider-managed function that ensures all sites on the server serve content over encrypted connections. Server-level brute force protection that blocks IP addresses generating excessive failed authentication attempts across the server is provider territory. These protections form a security baseline that a well-managed shared hosting platform provides to every tenant by default, without requiring individual site owners to configure or maintain them. When these protections are present and properly configured — as they are on every Hosting Captain shared hosting plan — the security posture of the hosting environment itself is robust against the majority of automated attack traffic.

Where Your Responsibility Begins

The demarcation line for shared hosting security is the application layer — your content management system, its themes and plugins, and any custom code you have installed. Your hosting provider cannot patch vulnerabilities in your WordPress plugins; that is your responsibility. They cannot enforce strong passwords on your CMS admin accounts; that is your responsibility. They cannot ensure that your contact form has proper input validation or that your file upload functionality restricts allowed file types; that is your development responsibility. They cannot prevent you from installing a nulled premium plugin downloaded from a questionable source that contains a backdoor; that is a decision you make (and one you should never make). The provider can block known attack patterns at the WAF level, but they cannot fix the underlying application vulnerabilities that the WAF is protecting — and WAF rules can be bypassed by attackers who craft exploits specifically designed to evade common rule sets.

This division of responsibility is the reason that two sites on the same shared hosting server can have dramatically different security outcomes. One site owner who updates WordPress core, plugins, and themes within 48 hours of release, uses strong unique passwords with two-factor authentication, runs a security plugin that monitors file integrity, restricts file permissions to the minimum necessary, and takes regular off-server backups will likely never experience a compromise — even on the same server where a neighboring site that has not been updated in two years, uses "admin" / "password123" as credentials, and has twenty abandoned plugins with known vulnerabilities is compromised within weeks of launch. The hosting environment provides the security floor; your application hygiene determines how far above that floor your site operates. For the network-level security considerations that complement application security, our guide on shared vs. dedicated IP addresses in shared hosting explores how IP configuration affects email deliverability and SSL compatibility — two security-adjacent considerations that directly impact your site's trust signals.

Practical Security Steps for Shared Hosting Site Owners

CMS Hardening Checklist

1. Keep everything updated. Apply WordPress core, plugin, and theme updates within 48 hours of release. Enable automatic updates for minor WordPress core releases and for plugins that have a reliable track record of not breaking sites with updates. Subscribe to the security mailing lists or vulnerability databases relevant to your CMS and plugins so you are aware of critical patches immediately.
2. Delete unused themes and plugins. Every inactive plugin and theme on your site is an additional attack surface that receives no security scrutiny. If you are not using it, remove it entirely — deactivation is not sufficient, as many vulnerabilities can still be exploited on deactivated but present code.
3. Use strong, unique passwords for every account. The WordPress admin password, the hosting control panel password, the database password, the FTP/SFTP password, and every user account on your site should be a unique, randomly generated password of at least 16 characters stored in a password manager. Never reuse passwords across services.
4. Implement two-factor authentication. Install a 2FA plugin for WordPress (Wordfence includes this, or standalone options like Two Factor Authentication by Plugin Contributors) and enable it for all administrator and editor accounts. If your hosting control panel supports 2FA — cPanel and DirectAdmin both do — enable it there as well.
5. Restrict file permissions. Directories should be set to 755 and files to 644 on a properly configured Linux shared hosting environment. The wp-config.php file should be set to 400 or 440 to prevent it from being readable by other system users. Never set any directory to 777, which grants read, write, and execute permissions to everyone.
6. Install a security plugin. Wordfence, Sucuri Security, or iThemes Security provide firewall rules, malware scanning, login attempt limiting, file integrity monitoring, and security hardening guidance within the WordPress dashboard. The free versions of these plugins provide substantial protection; the premium versions add real-time threat intelligence feeds and more sophisticated firewall rules.
7. Disable XML-RPC if not needed. WordPress's XML-RPC endpoint is a common target for brute force amplification attacks because a single XML-RPC request can attempt multiple username-password combinations. If you do not use the WordPress mobile app, Jetpack, or remote publishing tools that depend on XML-RPC, disable it via your security plugin or with a .htaccess rule.
8. Configure automated off-server backups. Install a backup plugin (UpdraftPlus, BackWPup, or BlogVault) configured to automatically back up your files and database on a daily schedule and store the backups in an off-server location — cloud storage like Google Drive, Dropbox, Amazon S3, or Backblaze B2. A backup stored on the same server as your site is not a backup if the server fails or the account is suspended.

File Upload Security

File upload functionality is one of the most common entry points for attackers on shared hosting sites because it allows external users to place files on your server. If your site includes any file upload capability — a contact form with an attachment field, a user profile picture upload, a document submission form, a media library that accepts uploads from registered users — secure configuration is critical. Restrict allowed file types to only the specific formats your site genuinely needs to accept; never allow .php, .phtml, .php5, .shtml, .cgi, .pl, or any other executable file extension in an upload directory. Configure file upload size limits to prevent resource exhaustion attacks. Store uploaded files in a directory outside the web root when possible, or at minimum in a directory with PHP execution disabled via a .htaccess rule (php_flag engine off for Apache or a RemoveHandler directive). Rename uploaded files using a random or hashed filename rather than preserving the original filename, which can include path traversal characters or executable extensions. Scan all uploaded files for malware if your hosting provider offers this service, or integrate a plugin that provides upload-time malware scanning.

When Shared Hosting Security Is Not Enough

Shared hosting security, even on a well-configured platform with diligent site owner practices, has inherent limitations that make it inappropriate for certain types of websites and data. If your website collects, processes, or stores sensitive personal information — healthcare data subject to HIPAA, payment card information subject to PCI DSS, personally identifiable information of EU residents subject to GDPR, or financial account information — the multi-tenant architecture of shared hosting introduces compliance risk that is difficult to fully mitigate. PCI DSS Level 1, for example, requires that cardholder data be stored in an isolated environment where access is restricted to specifically authorized individuals, a requirement that is challenging to satisfy in shared hosting where the provider's system administrators have root access to the server and where neighboring tenants' activity cannot be fully controlled or audited.

If your website generates significant revenue or is critical to your business operations, the passive risk of shared hosting — where another tenant's compromise can degrade your site's performance, reputation, or availability — may outweigh the cost savings. A VPS provides dedicated resources and complete isolation from other tenants, allowing you to implement security measures that are impossible in a shared environment, such as custom firewall rules with iptables, kernel-level auditing, file integrity monitoring with AIDE or Tripwire, and full-disk encryption. The cost premium for a VPS over shared hosting is a form of insurance against the operational and reputational costs of being collateral damage in another tenant's security incident. For businesses that have reached this inflection point, our complete VPS hosting guide details the migration path and what the security landscape looks like when you control the entire virtual server environment.

How Hosting Captain Evaluates Shared Hosting Security

When we assess shared hosting providers for our recommendations at Hosting Captain, security is not a binary pass/fail criterion but a multi-dimensional evaluation that examines the full stack from physical data center security through application-layer protections. The minimum requirements we enforce are CloudLinux with CageFS (or equivalent isolation technology with similar guarantees), PHP execution under per-account user IDs via PHP-FPM or FastCGI with suexec, a web application firewall (ModSecurity or equivalent) deployed with actively maintained rulesets, automated SSL certificate provisioning and renewal, server-level brute force protection with fail2ban or similar, and automated operating system patching with a defined SLA for critical vulnerabilities. Providers that do not meet this baseline are excluded from our recommendations regardless of their pricing or feature set.

Beyond the baseline, we evaluate additional security factors that differentiate good providers from excellent ones: proactive malware scanning that runs regularly across all accounts and alerts both the provider's security team and the account owner when infections are detected; automated cleanup tools that can remove common malware strains without manual intervention; IP reputation monitoring that detects when a server's IP address appears on email or web blacklists and triggers investigation; DDoS mitigation capacity that can absorb volumetric attacks without degrading service for other tenants; and transparent incident communication that informs affected customers promptly when security events occur rather than allowing them to discover issues through their own monitoring. These factors do not appear on feature comparison charts, but they determine whether a provider's security posture is genuinely protective or merely meeting the minimum requirements to claim security as a feature on their marketing page. Hosting Captain's own shared hosting platform implements all of these protections as standard, and we publish our security architecture transparently because we believe informed customers are the best audience for a security-focused hosting service.

Frequently Asked Questions

Is shared hosting safe for a small business website?

Yes, for the majority of small business websites — brochure sites, blogs, portfolio sites, and small e-commerce stores that do not store payment card data on the server — modern shared hosting with proper isolation technologies (CloudLinux, CageFS, PHP-FPM per-user execution) is adequately secure. The key variable is not the hosting type but the site owner's application hygiene: keeping CMS software updated, using strong unique passwords, implementing two-factor authentication, and taking regular off-server backups. A well-maintained WordPress site on quality shared hosting is more secure than a neglected site on a dedicated server.

Can other websites on my shared server hack my website?

On a properly configured modern shared hosting platform with CageFS or equivalent filesystem isolation, the risk of a compromised neighboring account directly reading or modifying your website's files is low. However, indirect effects are real: a DDoS attack against another tenant can degrade your site's performance, a spam campaign from a compromised account can blacklist the shared IP address affecting your email deliverability, and a brute-force attack against another site can consume server resources your site relies on. These indirect risks cannot be fully eliminated in a multi-tenant environment.

What security features should I look for in a shared hosting plan?

Ask the provider directly about: whether they deploy CloudLinux with CageFS for account isolation; how PHP scripts are executed (PHP-FPM with per-user pools is the standard); whether a web application firewall like ModSecurity is active; whether automated malware scanning runs on all accounts; whether automated backups are included and where they are stored; what brute-force protection is in place at the server level; and what their incident response process looks like when a compromise is detected. If the provider cannot answer these questions clearly and specifically, consider it a red flag.

Do I need a dedicated IP address for better security on shared hosting?

A dedicated IP address does not meaningfully improve your site's security in a shared hosting environment — it affects email deliverability, SSL compatibility for older clients, and certain application requirements like payment gateway integrations, but it does not change the multi-tenant architecture or your exposure to cross-account risks. The isolation technologies (CageFS, PHP-FPM per-user execution) operate at the operating system level and are identical regardless of whether you have a shared or dedicated IP. Do not purchase a dedicated IP expecting it to improve security; purchase it only if you have a specific technical requirement that demands one.

What should I do if my shared hosting site gets hacked?

Contact your hosting provider's support team immediately — they may be able to suspend the account to prevent further damage, provide server-level malware scans, and help identify the entry point. Change all passwords associated with the site — hosting control panel, CMS admin, database, FTP/SFTP, and email accounts. Restore the site from a clean backup if one is available. If no clean backup exists, engage a malware cleanup service (Sucuri, Wordfence, or a security-focused developer) to remove the infection. After cleaning, identify and patch the vulnerability that allowed the compromise, update all software, audit user accounts for unauthorized additions, and submit the site for review to Google Search Console to lift any Safe Browsing warnings. Finally, implement the hardening measures described in this guide to prevent recurrence.