Restricting Web Server Privileges

Restricting Web Server Privileges (Hardening the Service Account)

Running Modes and Their Privileges

The Hearth Portable Web Server can run in two different modes. Each mode runs under a different Windows account, which determines what the hosted web application is allowed to do and which files your user account can access afterward. Understanding this distinction is the foundation for everything else on this page.

Mode 1 — Manual mode (launcher)

In this mode you control the server interactively through the launcher window:

• Start: open the launcher and click [Start].
• Stop: click [Stop], or simply close the launcher window (closing the launcher stops the server).

The server only runs while you are logged in and the launcher session is active. There is no auto-start; when you log off or close the launcher, the server stops.

Application privilege. In this mode the web server runs as your own Windows user account — the same account you used to start the launcher. The hosted application therefore has exactly your permissions: it can read, write, and run anything you can, and no more. If you start the launcher normally, that means standard-user rights. If you start it with Run as administrator, the application runs elevated with administrative rights for that session.

File access. Because the server runs as you, every file the web application creates is owned by your account. You can freely read, edit, move, and delete those files in File Explorer with no permission prompts, because they belong to you. This mode never produces the "files I can't modify" situation, and no special folder permissions are applied.

This mode is ideal for development, testing, and learning, where you want full and immediate access to whatever the application produces.

Mode 2 — Auto-start mode (Windows Service)

In this mode the server is installed as a Windows Service so it starts automatically with the computer and runs in the background — without requiring any user to be logged in. This is the mode to use when you want the site to be continuously available, for example on a machine acting as a small server.

Because a service must run without a logged-in user, it cannot run as "you." Instead it runs under a dedicated Windows service account. By default, Hearth installs the service to run as LocalSystem, the highest-privilege local account, so the hosted application works without permission friction. The trade-off is that this is also the most permissive configuration, and the files the service creates are owned by SYSTEM rather than by you — which is why Hearth automatically grants your user account access to the web root at install time (explained below).

The remainder of this page focuses on this auto-start (Windows Service) mode: why its default privileges are set as they are, and how to restrict them if you need a more locked-down configuration.

Why restrict privileges

A web application hosted by Hearth runs as full-trust .NET code. It inherits whatever privileges the service account has. When the service runs as LocalSystem:

• The application can write to or delete any file on the machine.
• Any process the application starts also runs as LocalSystem, inheriting full control of the computer.
• A vulnerability in the hosted application (for example, an insecure file upload) could be leveraged to take over the entire machine.

Switching the service to a low-privilege account confines the application — and anything it spawns — to a much smaller set of permissions.

Important: two separate steps are required

Lowering privilege correctly involves two independent changes. Doing only one leaves a gap:

1. Change the service's Log On account — controls what the application (and any process it launches) is allowed to do system-wide.
2. Tighten the web root folder permissions — controls who can write to the application's files.

When the service is installed, Hearth grants Authenticated Users modify access to the web root so your user account can freely edit files created by the service. Changing the Log On account alone does not remove this folder permission. To fully restrict the application, you must do both steps below.

Step 1 — Change the service Log On account

1. Press Win + R, type services.msc, and press Enter.
2. In the Services list, locate your Hearth service. It is named HearthPortableWebServer_Port<port> (for example, HearthPortableWebServer_Port8080), with the display name Hearth Portable ASP.NET Web Server (port <port>).
3. Right-click the service and choose Properties.
4. Go to the Log On tab.
5. Select This account, then enter one of the built-in low-privilege accounts described below.
6. Leave the password fields blank for the built-in accounts (they require no password).
7. Click OK.
8. Back in the Services list, right-click the service and choose Restart so the change takes effect.

Choosing a low-privilege account

Account	Type in the box	Use when
Local Service	NT AUTHORITY\LocalService	The application only needs local resources. Most restrictive; presents anonymous credentials on the network.
Network Service	NT AUTHORITY\NetworkService	The application must authenticate to network resources (for example, a SQL Server on another machine using Windows authentication).
A dedicated user	.\<username> (local) or <domain>\<username>	You want a specific, named identity with permissions you control. Requires a password.

Both Local Service and Network Service are built into Windows, require no password, and are the recommended choices for confining the application.

Step 2 — Tighten the web root folder permissions

After changing the Log On account, remove the broad write access that was granted at install time, then grant write access only where the application actually needs it.

Remove broad write access

1. In File Explorer, right-click the web root folder (the folder you configured as the web application root) and choose Properties.
2. Go to the Security tab and click Edit.
3. In the list, select Authenticated Users.
4. Click Remove, then OK.

This makes the application's files read-only to standard accounts, so the hosted application can no longer overwrite its own pages, configuration, or binaries.

Grant write access only to a data folder

Most applications still need to write somewhere (uploads, logs, a local database). Grant write access to a single dedicated subfolder rather than the whole root:

1. Create a subfolder inside the web root for writable data — for example, App_Data.
2. Right-click that subfolder, choose Properties, then the Security tab, then Edit, then Add.
3. Enter the same account you set in Step 1 (for example, NT AUTHORITY\LocalService) and click Check Names, then OK.
4. With that account selected, enable Modify under Allow, then click OK.

Naming the folder App_Data is recommended: ASP.NET does not serve files from App_Data over HTTP by default, so files written there cannot be requested and executed as web pages. Configure your application to write uploads and other generated files into this folder.

Verifying the change

After completing both steps and restarting the service:

• Open services.msc, view the service's Properties → Log On tab, and confirm it shows the low-privilege account you selected.
• Confirm the application still functions and can write to its designated data folder.
• Confirm that attempts to write outside the data folder now fail, which indicates the restriction is in effect.

Reverting to full privilege

To return to the default convenient configuration:

1. In services.msc, open the service's Properties → Log On tab, select Local System account, and click OK.
2. Restart the service.
3. Optionally, re-add Authenticated Users with Modify permission on the web root folder (Security tab → Edit → Add), or simply uninstall and reinstall the service, which reapplies the default permissions automatically.