Security Analysis for this repository

[ahallctr-jpg]

Hey folks,

Since Anthropic release Opus 4.6, they actually warned about "AI fixes" for security problems that don't exist and pointed out that Opus was actually really good at identifying security concerns. So I ran it against this repository. Here is what it found:

1. Data leakage on Create conflicts (HIGH)

When a Create hits a duplicate ID for another user, the response can leak that user's entity data.

MITIGATION: The documentation warns about this, but the framework doesn't mitigate it.

DISCUSSION: Unfortunately, because we are talking about developer-provided code here (I don't actually enforce a specific schema for user records), there isn't much I can do. However, I'm thinking of using the access control provider so that the user record is not provided if the IAccessControlProvider says the duplicate record is not visible. I think this will explicitly fix this. Tracking issue #445

2. Sensitive data logged at information level (HIGH)

The Full entity JSON is logged via entity.ToJsonString() in Create, Replace, Read, and auth failure paths. This potentially writes PII/secrets to production logs.

MITIGATION: None

DISCUSSION: I will add an option to the table options that either enables or disables the unsafe logging. The entity will be logged at the debug level and only the entity ID will be logged at the information level. The default will be "safe" logging, but all the samples will have unsafe logging turned on.

3. Default AccessControlProvider Allows All Operations (MEDIUM)

MITIGATION: Developer provides a custom access control provider.

DISCUSSION: This is a "security issue" that I am not going to fix. However, I'm open to building and distributing "custom access control providers" for common situations, if folks feel this is a problem.

4. UnauthorizedStatusCode is Configurable to Arbitrary Values (MEDIUM)

UnauthorizedStatusCode defaults to 401 but can be set to any integer, including success codes (e.g., 200). A misconfiguration could silently turn authorization failures into successful responses. No validation is performed on this property.

DISCUSSION: I'll be adding code into TableControllerOptions.cs that limits the UnauthorizedStatusCode to 4xx to prevent accidental misconfiguration. Tracking issue #447

5. OData Query Features All Enabled with High Limits (MEDIUM)

All OData query features ($filter, $orderby, $select, $count) are enabled by default with no way to disable them. MAX_TOP and MAX_PAGESIZE are both 128,000. This creates a potential for:

• Resource exhaustion: Large $top values can cause the server to load massive result sets
• Data enumeration: $filter combined with $orderby and $count can be used to extract information about the dataset even when $select limits visible fields
• Timing attacks: Complex $filter expressions could be used to infer data via query timing

DISCUSSION: I'm not going to be doing anything about this, except maybe in documentation.

6. Replace Operation Authorizes Against Old Entity but Commits New Entity (MEDIUM)

Authorization is checked against the existing entity (line 44), but PreCommitHookAsync and Repository.ReplaceAsync operate on the new entity from the request body (lines 52-53). A user could submit a replacement entity that changes fields used for access control (e.g., an OwnerId field), and the authorization check wouldn't catch it because it validates the old entity. The PreCommitHookAsync is the only defense, but it's optional.

DISCUSSION: As with the concern above, this is by design and I'm not going to do anything about this (although I guess I could potentially authorize against the old and new entity, ensuring the new entity is in view as well). I will document this case though.

LOW Severity concerns

There are two low severity concerns:

1. The sample logging handlers log the full HTTP body (correct and I'm not going to change that)
2. There is no rate limiting on API endpoints (also correct and ASP.NET has facilities for this that I'm not going to duplicate)

What do folks think? Should I do anything about points 5 and 6?

[ideas2appsaustralia]

Adrian Do you intend to make these fixes in Datatsync 6.1 as well? Scott

…

________________________________ From: Adrian Hall ***@***.***> Sent: Tuesday, March 10, 2026 3:18 AM To: CommunityToolkit/Datasync ***@***.***> Cc: Subscribed ***@***.***> Subject: [CommunityToolkit/Datasync] Security Analysis for this repository (Discussion #448) Hey folks, Since Anthropic release Opus 4.6, they actually warned about "AI fixes" for security problems that don't exist and pointed out that Opus was actually really good at identifying security concerns. So I ran it against this repository. Here is what it found: 1. Data leakage on Create conflicts (HIGH) When a Create hits a duplicate ID for another user, the response can leak that user's entity data. MITIGATION: The documentation warns about this, but the framework doesn't mitigate it. DISCUSSION: Unfortunately, because we are talking about developer-provided code here (I don't actually enforce a specific schema for user records), there isn't much I can do. However, I'm thinking of using the access control provider so that the user record is not provided if the IAccessControlProvider says the duplicate record is not visible. I think this will explicitly fix this. Tracking issue #445<#445> 2. Sensitive data logged at information level (HIGH) The Full entity JSON is logged via entity.ToJsonString() in Create, Replace, Read, and auth failure paths. This potentially writes PII/secrets to production logs. MITIGATION: None DISCUSSION: I will add an option to the table options that either enables or disables the unsafe logging. The entity will be logged at the debug level and only the entity ID will be logged at the information level. The default will be "safe" logging, but all the samples will have unsafe logging turned on. 3. Default AccessControlProvider Allows All Operations (MEDIUM) MITIGATION: Developer provides a custom access control provider. DISCUSSION: This is a "security issue" that I am not going to fix. However, I'm open to building and distributing "custom access control providers" for common situations, if folks feel this is a problem. 4. UnauthorizedStatusCode is Configurable to Arbitrary Values (MEDIUM) UnauthorizedStatusCode defaults to 401 but can be set to any integer, including success codes (e.g., 200). A misconfiguration could silently turn authorization failures into successful responses. No validation is performed on this property. DISCUSSION: I'll be adding code into TableControllerOptions.cs that limits the UnauthorizedStatusCode to 4xx to prevent accidental misconfiguration. Tracking issue #447<#447> 5. OData Query Features All Enabled with High Limits (MEDIUM) All OData query features ($filter, $orderby, $select, $count) are enabled by default with no way to disable them. MAX_TOP and MAX_PAGESIZE are both 128,000. This creates a potential for: * Resource exhaustion: Large $top values can cause the server to load massive result sets * Data enumeration: $filter combined with $orderby and $count can be used to extract information about the dataset even when $select limits visible fields * Timing attacks: Complex $filter expressions could be used to infer data via query timing DISCUSSION: I'm not going to be doing anything about this, except maybe in documentation. 6. Replace Operation Authorizes Against Old Entity but Commits New Entity (MEDIUM) Authorization is checked against the existing entity (line 44), but PreCommitHookAsync and Repository.ReplaceAsync operate on the new entity from the request body (lines 52-53). A user could submit a replacement entity that changes fields used for access control (e.g., an OwnerId field), and the authorization check wouldn't catch it because it validates the old entity. The PreCommitHookAsync is the only defense, but it's optional. DISCUSSION: As with the concern above, this is by design and I'm not going to do anything about this (although I guess I could potentially authorize against the old and new entity, ensuring the new entity is in view as well). I will document this case though. LOW Severity concerns There are two low severity concerns: 1. The sample logging handlers log the full HTTP body (correct and I'm not going to change that) 2. There is no rate limiting on API endpoints (also correct and ASP.NET has facilities for this that I'm not going to duplicate) What do folks think? Should I do anything about points 5 and 6? — Reply to this email directly, view it on GitHub<#448>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AXS3BMS2EFZHATNDO4OJSRT4P3VFFAVCNFSM6AAAAACWMBZS2GVHI2DSMVQWIX3LMV43ERDJONRXK43TNFXW4OZZGYYDQMJXGM>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[ahallctr-jpg]

No - There is no way for me to release a 6.x version of datasync at this point.