Was this page helpful?
Your feedback about this content is important. Let us know what you think.
Additional feedback?
1500 characters remaining
Export (0) Print
Expand All

Web Application Security at Design Time in Visual Studio

When you are working in Visual Studio to create your Web application, there are specific requirements for security that pertain to your access to resources you need during development. These requirements are distinct from those that apply to users of your application. At design time, your security requirements include:

  • Accessing your working server, database server, and other resources that are part of your application.
  • What Web access method you choose (how you transfer data to the Web server).
  • Running code as fully trusted.
  • Debugging.
  • Deploying your application.

Accessing Development Resources

In order to create and test Web applications in Visual Studio, you must have access to a computer running Internet Information Services (IIS). On this server — a development server, as distinct from the production server where you deploy your application — you must have certain minimum privileges, including the ability to write files to the server and run them.

The Web server does not have to be on the same computer you use for development. However, you must install at least the server components of Visual Studio on the Web server so that it supports debugging and deployment for your application.

Design-time access to resources is typically handled using Windows NT authentication — that is, as a developer, you use your network login credentials to get access to resources you need. When Visual Studio is installed, it creates a group on the server called VS Developers. This group has all necessary file, share, and IIS permissions required to be able to develop Web projects on that machine. (The computer administrator can further configure customize permissions for the group, but it is not necessary.) As a developer, you must be part of this group, either as an individual or as part of another group that you belong to. The specific rights granted to the VS Developer group are:

  • Access to the wwwroot directory of the Web server computer.
  • Permissions to create, modify, and execute files in the Web directories.
  • Permission to debug remote Web applications.
    Security Note   Developers do not need to have administrative rights on a server in order to develop with it. (However, all developers must be members of the VS Developers group.) Granting developers unnecessary administrative permissions can constitute a security risk for your network.

If your application needs access to further resources, you must likewise establish access rights to those, either for yourself individually or as part of a group. A typical example is a SQL Server. As a Web application developer, you will need to be able to read and possibly update the database tables required for your application. For some scenarios, you will also need permission to write stored procedures to the server; in others, you might need permission to add, alter, or drop tables.

Web Access Methods

Visual Studio allows you to access your Web application projects in two ways:

  • Using file-share access (UNC access), in which Visual Studio copies files to the server using Windows-based file management commands.
  • Using FrontPage Server Extensions access, in which files are transferred using HTTP.

File-share access requires that you be on the same domain as the Web server. In practical terms, this means you can use file-share access only on your network.

FrontPage access, in contrast, allows you to create and manage your application across a firewall (as long as the firewall passes HTTP requests). This makes it possible to work across the Internet (or, of course, in a local setting where you prefer HTTP access).

Both access methods still require that the server be configured appropriately with the Visual Studio server components, the VS Developers group, and so on. Similarly, you still need sufficient privileges on the server to be able to create, write, and run files.

For more information, see Web Access Methods.

Running Code as Fully Trusted

When Visual Studio is running, user code that is run by the designer at design time will always run fully trusted. This is true even if the code will eventually be deployed to an environment that runs with more restrictive security. This has two implications:

  • It is possible to expose your local computer to a security risk by importing unsecure code into a project. Because Visual Studio runs in fully trusted mode, imported code inherits its permissions from Visual Studio, and the unsecure code will be run as secure code. This would only be a concern in the case of a malicious user creating a damaging piece of code (for example, a custom control) that you then inadvertently import and run. You must therefore take extra care when importing code into your project.
  • Applications that you create in Visual Studio might fail to work properly when deployed because the code is running in a different security context.
  • For more information, see Code Access Security.


Debugging requires that you be able to attach to processes running on your computer or, if the Web server is on another computer, on a remote computer. Debugging requires that you run with Administrator privileges. If you are debugging on a remote computer, you must have these permissions on both your computer and on the remote computer.

When Visual Studio is installed, it creates a group called Debugger Users that has the required permissions to be able to debug. Having separate groups for developers and for debugging users allows the server administrator to grant the privileges necessary for debugging to a more select group than everyone who uses Visual Studio.

Security Note   Membership in the Debugger Users group effectively grants users administrative-level privileges. Do not make anyone a member of this group who should not have this level of privilege.

For more information, see Introduction to Web Application Debugging.

Deploying Your Application

When the application is finished, you must be able to deploy it to the production server. If the production server does not belong to you, you might have much more limited access to the server than you do to your development server.

One way to deploy a Web application is to use Visual Studio deployment tools. This type of deployment allows you to perform a complete installation of your application, including registration and configuration. However, it requires that you have administrative rights to the computer hosting the Web server.

Alternatively, if FrontPage server extensions are installed on the production server, you can deploy using HTTP using the Copy Project command. This type of deployment provides you with fewer deployment features, but allows you to deploy across a firewall. You must still have sufficient privileges on the target server to be able to write files to it.

For details about deploying Web applications, see Deployment of a Web Setup Project.

See Also

Security Model | Introduction to Web Projects | Working with Web Projects | Walkthrough: Deploying a Web Solution

© 2015 Microsoft