Developer Docs

Handling security in C#Bot server-side

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:

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:

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


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 CRUD (create, read, update and delete) events are logged directly to the system logger with mutation events (create, update and delete) being logged using Audit.Net. Read audits are handled separately but are also redirected to the system logger.

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; }

Was this article helpful?

Thanks for your feedback!

If you would like to tell us more, please click on the link below to send us a message with more details.







On this page

New to Codebots?

We know our software can be complicated, so we are always happy to have a chat if you have any questions.