Handling security in C#Bot server-side

A guide for developers who want to understand the security of their CsharpBot applications so that they can use it in custom code.

One of Codebots’ highest priorities is the security of the software which our codebots write, to the point where a diagram was made to focus on that sole purpose. This same level of care and attention was given to developing SpringBot’s security strategy.

When it comes to security, we categorise all work into the three A’s:

  • Authentication,
  • Authorisation, and
  • Auditing

For authentication C#Bot utilises ASP.NET Identity to provide user identity services across the framework as well as OpenIddict for generating API tokens. For auditing the library Audit.NET is used for recording a log of user interactions with the application. All of which has been implemented on top of our security standard which ensures all third generation bots have the same level of security across the software stack.

This article will explore C#Bots’s security strategy, focusing on how to customise the three A’s within your application.

We recommend all readers also explore the security strategy for C#Bot, which has been documented in the security documentation section of your Reference Library.


In regards to Authentication, all of the logic required for validating and generating user login tokens is found in serverside/src/Services/UserService.cs.

The general flow for a user logging in is as follows:

  • User hits the login endpoint in serverside/src/Controllers/AuthorizationController.cs
  • The controller calls the user service to validate the provided credentials
  • The user service returns a token for a validated user with the user’s claims embedded inside of it
  • The controller returns the token as a cookie or JWT token to the user that can be used to authenticate future requests

The general flow for an authenticated user requesting a protected endpoint is as follows:

  • User hits the protected endpoint with a cookie or JWT token embedded inside of the request
  • The token is deserialised into a claims principal by ASP.NET and C#Bot will use those claims to authenticate the user
  • If required the user is passed down from the controller into the service layer for any further authorisation purposes


Any managed CRUD actions that occur in a C#Bot application occur in serverside/src/Services/CrudService.cs. This includes the regular create, read, update, and delete operations as well as other related features such as CSV export. The crud service acts as a managed layer over the underlying database service to apply security filtering on any operations that occur. It does this by calling serverside/src/Services/SecurityService.cs which reads the rules that have been created in the security diagram and either applying filtering operations or introspecting changes that are going to be applied, and then accepting or rejecting them.

All bot written endpoints use the crud service for accessing entities specified in the entity diagram. If there is a case where the security rules need to be bypassed the underlying database context can be reused to escape any restrictions.

The best way to modify any security related features is through the Security Diagram.


By default, auditing is enabled and can be used to track the changes of the data within the application. All auditing operations are handled by the library Audit.NET. The auditing strategy that is used in C#Bot is the log all changes to a single database table called AuditLog, which has a complete history of every operation performed on the database. It does this by hooking into the database content and recording any operations that occur.

An example audit log for inserting a new entity called region will have the following structure.

Column Name Data Description
Id 156bfae2-665f-4001-b643-6d4ccc3e5c6a The ID of the audit
UserId a1ef313f-3623-490b-b0d4-388b24131719 The ID of the user that performed the action
EntityType Region The type of entity that the operation occured on
Action Insert The type of action that occured
TablePk f84a186e-9dbd-4f10-abe3-76144078197f The primary key of the item that was operated on
AuditDate 2019-10-09 05:12:56.666824 The date when the audit occured in UTC
AuditData {"Table":"Region","Action":"Insert","PrimaryKey":{"Id":"f84a186e-9dbd-4f10-abe3-76144078197f"},"ColumnValues":{"Id":"f84a186e-9dbd-4f10-abe3-76144078197f","Created":"2019-10-09T15:12:56.5704656+10:00","Modified":"2019-10-09T15:12:56.5703697+10:00","Owner":"a1ef313f-3623-490b-b0d4-388b24131719","RegionName":"My New Region","RegionRadius":19},"Values":null} The audit values in JSON format
HttpContextId 0HLQCESC51VJJ:00000001 The ID of the HTTP request from ASP.NET

Auditing Sensitive Data

Not all data should be audited, such as if it is of a sensitive nature. These fields can be specified in the code by marking the field as ignored by the auditing framework. An example of this can be found in serverside/src/Models/User.cs in which the password hash of a user is ignored by the framework to make sure it is not logged.

// Need to import the auditing framework
using Audit.EntityFramework;

// In the model class
public override string PasswordHash { get; set; }

Ready to start building?

Sign up to Codebots today to see how much faster you can build apps with us.