Security in Web Pages

The WebSecurity helper class provides membership functionality out of the box, storing user accounts in a database configured via WebSecurity.InitializeDatabaseConnection, typically called once in _AppStart.cshtml with the account table name, user id column, and username column specified explicitly. WebSecurity.CreateUserAndAccount(username, password) hashes the password and creates both the membership record and an optional profile row in one call, while WebSecurity.Login(username, password) verifies credentials and issues the authentication cookie that keeps a visitor signed in across subsequent requests without re-entering credentials on every page.

Guarding a page requires checking WebSecurity.IsAuthenticated before rendering sensitive content, or applying it at the top of a protected page with a pattern like if (!WebSecurity.IsAuthenticated) { Response.Redirect("~/Account/Login"); }, since Web Pages has no built-in [Authorize] attribute the way MVC does. Because every protected page must repeat this check, many Web Pages sites factor the logic into a shared helper file included near the top of each restricted page, or rely on a folder-level _PageStart.cshtml that runs before every page in that directory and can redirect unauthenticated visitors before the page body executes.

Beyond simple authentication, the SimpleRoleProvider adds authorization by grouping users into named roles; Roles.AddUsersToRole(username, "Admin") assigns a role, and a page checks membership with WebSecurity.IsUserInRole("Admin") before exposing administrative functionality like deleting other users' content. Because these role checks are ordinary C# conditionals rather than declarative attributes, a developer must remember to add the check to every relevant page and every relevant action within that page, including AJAX-style handlers that might otherwise be reachable without going through the page's main rendering path.

Razor's @variable output is HTML-encoded by default, so displaying user-submitted text like a comment automatically neutralizes embedded <script> tags, closing off the most common cross-site scripting vector without extra effort; explicitly opting out with @Html.Raw() should be reserved for content the developer trusts completely. Cross-site request forgery is addressed with @AntiForgeryToken() emitted inside a form and validated on post with AntiForgery.Validate(), which confirms the submission actually originated from the site's own rendered form rather than from a malicious page that tricked a logged-in user's browser into submitting a hidden request.