Security Issues in Dynamics 365 Solutions

When security in Dynamics 365 comes up, many people think of attacks from outside. The real problems in solutions look different: they are configurations that allow more than intended and that go unnoticed for years because they do not produce an error. The most common patterns, ordered by the damage they can do.

Roles that are allowed too much

How to go through the role inventory systematically is something I will cover in a separate post in the near future. Security roles sit in the solution export with every single privilege, and that is where the most common problem is found: privileges at organization level where business unit would have been enough, delete privileges for roles that should only read, and roles that were opened up further and further during the project because something did not work and nobody looked for the actual cause.

The last pattern deserves a sentence of its own: extending privileges until the error goes away is a widespread debugging method. The extensions then stay forever. Anyone reviewing a role should therefore not ask whether it works, but whether every single privilege has a justification.

Sensitive fields without field security

Salary data, health notes, bank details: such fields exist in many environments, and table access only controls who sees the record, not who sees the field. That is what field security profiles are for, and their absence can be read from the export: fields whose names suggest sensitive content, without field security being enabled, are worth at least a follow-up question.

Cascading delete on the wrong relationship

Relationships with cascading delete behavior remove dependent records along with the parent. On the relationship between order and order line that is correct and quite intended behavior. On the relationship between an account and all of its activities it means that deleting a single account silently takes its entire history with it, even when valuable information is stored in those activities. The cascade behavior of every relationship is in the solution export, and the combination of delete privilege plus cascade is the point where an accident turns into data loss.

The rest of the list

On top of that come the patterns from the JavaScript world, insecure scripts and unencrypted calls. The Solution Checker catches part of them, such as eval or direct innerHTML assignments; what it covers is described in what is the Microsoft Solution Checker. And then there are endpoints to the outside: webhooks and service endpoints that send data to external targets. These are not a problem per se, but every target should be known and current. A webhook pointing at an address that nobody can attribute anymore is a data outflow that simply has not been noticed yet. How to take a systematic inventory of all these outbound routes is described in detecting critical configurations and data outflow.

Why this is more visible in the export than in the interface

The interface shows roles and relationships one at a time, spread across dozens of screens. The export shows them as a complete inventory, and security problems are almost always inventory problems: not the one wrong setting, but the pattern across 40 roles. A list of all delete privileges at organization level across all roles is tedious in the interface and a finger exercise from the export.

The uncomfortable truth at the end: none of these checks replaces the question of who actually gets the roles assigned. That is not in any export, it is in the environment, and it still belongs to the same inventory. Why it pays to deal with such risks before anything else is explained in why solution hygiene saves time and money.