Namespace CoreUpload.Security

Classes

CloudUploadSession

The server-issued facts about a direct-to-cloud upload, carried in a tamper-proof token so later calls in the same upload cannot change them.

Why this exists. The presign flow is several requests: create, sign parts, complete, abort. Only create chooses the object key; every later call receives the key and upload id from the client. Without binding, a caller can send any key it likes and have parts presigned for it, or complete and abort uploads it did not start because nothing ties those values to the session the server actually opened.

When RequireSignedCloudSessions is enabled the token is mandatory and the values inside it replace whatever the client sent, so a lying client cannot redirect the upload.

CloudUploadSessionTokenService

Issues and validates CloudUploadSession tokens.

Built on ASP.NET Core Data Protection, so key management, rotation and isolation are handled by the framework rather than by a hand-rolled HMAC. In a multi-server deployment the data protection keyring must be shared, exactly as it must be for antiforgery tokens.

RelativeUploadPath

Sanitizes the client-supplied folder-relative path that accompanies folder uploads (the relativePath form field / X-Upload-Relative-Path header / chunk-complete body property). The value is attacker-controlled text: it is never used to address storage directly — uploads are stored by GUID — but it is persisted and later handed to application code that may combine it into destination paths, so every traversal vector is removed here, once, before the value enters the system.

UploadSecurityContext

UploadSecurityData

Interfaces

IUploadAuthorizationHandler

Optional per-file authorization for the built-in endpoints.

Default behavior (no implementation registered): the endpoints are capability-based - anyone holding a file's GUID can read or delete it. The GUIDs are NewGuid() (v4, not enumerable), so this is the same security model as an unguessable share link. That is a deliberate default so the component works with zero configuration, but it means a GUID leaked through a referrer header, a log, or a screenshot grants access.

To scope files to a user/tenant, register an implementation:

builder.Services.AddSingleton<IUploadAuthorizationHandler, MyUploadAuthorization>();
public sealed class MyUploadAuthorization : IUploadAuthorizationHandler
{
public ValueTask<bool> AuthorizeAsync(HttpContext http, Guid fileGuid, UploadFileAction action, CancellationToken ct)
{
var owner = MyDb.GetOwnerOf(fileGuid);
return ValueTask.FromResult(owner == http.User.Identity?.Name);
}
}

Returning false makes the endpoint answer 404 (not 403) so a caller cannot probe which GUIDs exist.

Note that DELETE also honors CoreUploadOptions.EnableAntiforgery, which is off by default; turn it on (or authorize here) if a leaked GUID must not be deletable cross-site.

Enums

UploadFileAction

Actions the built-in endpoints perform on an already-stored file.