Introduction

Have you ever considered what it would be like to have a team of capable developers in your company and use Microsoft Dynamics as a back-office platform? 

When you talk to consultants and Dynamics CRM developers, they will say the platform is pretty safe because of its detailed security roles and data classification measures. They should feel secure about the data integrity. Based on their company’s business logic and the way they request a developer to set up security measures, most clients and users of Microsoft Dynamics feel safe and confident while using the platform. 

But we are not talking about a regular company. Our company has developers who know their way around data and software. Even when they have not used Microsoft Dynamics CRM, they can figure out ways to manipulate data even though they might not have a high-security role. 

Real World Scenario

Imagine this scenario: In the company that uses the Dynamics CRM platform, you have created a customized model-driven application that captures your co-workers’ check-in and check-out in the office. You carefully assign security roles and lock the time fields so that they can only see their records and cannot change the fields or even deactivate the record so that it would be displayed as a read-only record! 

But that won’t stop your developers from exploring around, is it? 

We have a co-worker who is always late. The boss has given him the ultimatum that being late is no longer tolerable. Your friend is late again and can’t tell the Dynamics administrator to alter his time sheet. 

How to Fix Loophole

So what should your friend do? He/she cannot change the record within Dynamics CRM! So, the only option left is from outside Dynamics CRM. What better way to access a listening endpoint than Postman? (assuming they are not aware of the LEVEL-UP browser extension for Dynamics 365/Power Apps) 

All your friend needs to do is figure out the logical names of your field, such as the Check-in field, State code, Status code, and the record ID, which all of these data are accessible from your browser! 

PS—Cookies are also accessible to you so that a random person cannot do the same thing. 

So something like this is created :  


https://YOUR_ORG.crm#.dynamics.com/api/data/v9.0/YOUR_APP 

--header 'Cookie: ARRAffinity=9715e5db89620c78116c45eb916a60e0ca-Something 

--header 'Content-Type: application/json' \ 

--data-raw '{ 

    "YOUR_RECORD@odata.bind": "/RECORD(GUID)", 

    " YOUR_RECORD @OData.Community.Display.V1.FormattedValue": "NAME", 

    "statuscode": 1, 

    "statecode": 0, 

    "Check-In-Time" : ” 2024-08-22T08:30:00.000Z”, 

    "ownerid@odata.bind": "/systemusers(GUID)", 

    "ownerid@OData.Community.Display.V1.FormattedValue": "JOHN WICK" 

}'

And presto manifesto, the request is sent, and the data is changed without anyone noticing! 

Now, the part for the Consultant/Developer:  

To prevent this breach, you will need to fully understand the goal and logic of your app so that you can prevent these methods of data manipulation. 

How? Well, you need to figure out which part of your data, under which circumstances, you don’t want it to change and create a specific C# plugin, for that matter. 

For example, as a Consultant/Developer, I wouldn’t want the Check-In time to be changed while the record is in an Inactive state, so I’ll just register a plugin that triggers on change of that field, and say if you are trying to change this data, if the state code is equal to 1, then throw an invalid plugin exception! – easy, right? Now, when other people send similar requests to our similar scenario, they receive the exception you put in, and your data remains safe from developers. 

Conclusion

Figure out all other scenarios in which something similar might happen and think ahead by preventing all of this.
That’s how you become a well-established Consultant/Developer!