Bug: Not respecting CORS policy causes blocked requests

[account00001]

I can access my image via URL fine but when I add processing commands to it, for example ?width=400, the request is blocked by CORS. I have my processing behavior set to ProcessingBehavior.CommandOnly.

Example of successful request without processing:

Example of CORS blocking with processing:

Example when I change processing behavior to ProcessingBehavior.All (request is blocked without processing)

It's blocked because the CORS header ‘Access-Control-Allow-Origin’ is missing on the response. I've configured my project to be setup with CORS via builder.Services.AddCors(...). I've added a default policy and allowed my origins. It seems responses generated by ImageSharp however are not respecting this policy.

I've searched the documentation and example projects but I couldn't find anything related to CORS.

Questions:

How can I configure CORS when I call services.AddImageSharp(...)?
or
How can I get ImageSharp to respect my existing CORS policy?

I'm on SixLabors.ImageSharp.Web v2.0.2 with .NET6. Happens in all browsers (tested with Firefox, Chrome, Edge).

[JimBobSquarePants]

You can use ImageSharpMiddlewareOptions.OnPrepareResponseAsync to further augment the response headers before sending.

It would be good to automate that though.

[JimBobSquarePants]

I'm not seeing this while testing it using the sample project in the repository.

/// <summary>
/// The running application.
/// </summary>
public static class Program
{
    /// <summary>
    /// The main application entry point.
    /// </summary>
    /// <param name="args">Argument paramateres.</param>
    public static void Main(string[] args)
    {
        WebApplicationBuilder builder = WebApplication.CreateBuilder(args);

        // Add services to the container.
        IServiceCollection services = builder.Services;
        services.AddRazorPages();

        // TODO: Enable HMAC
        services.AddImageSharp(options => options.HMACSecretKey = null) // new byte[] { 1, 2, 3, 4, 5 })
            .SetRequestParser<QueryCollectionRequestParser>()
            .Configure<PhysicalFileSystemCacheOptions>(options =>
            {
                options.CacheRootPath = null;
                options.CacheFolder = "is-cache";
                options.CacheFolderDepth = 8;
            })
            .SetCache<PhysicalFileSystemCache>()
            .SetCacheKey<UriRelativeLowerInvariantCacheKey>()
            .SetCacheHash<SHA256CacheHash>()
            .Configure<PhysicalFileSystemProviderOptions>(options => options.ProviderRootPath = null)
            .AddProvider<PhysicalFileSystemProvider>()
            .AddProcessor<ResizeWebProcessor>()
            .AddProcessor<FormatWebProcessor>()
            .AddProcessor<BackgroundColorWebProcessor>()
            .AddProcessor<QualityWebProcessor>()
            .AddProcessor<AutoOrientWebProcessor>();

        services.AddCors();

        WebApplication app = builder.Build();

        // Configure the HTTP request pipeline.
        if (!app.Environment.IsDevelopment())
        {
            app.UseExceptionHandler("/Error");

            // The default HSTS value is 30 days. You may want to change this for production scenarios, see https://aka.ms/aspnetcore-hsts.
            app.UseHsts();
        }

        app.UseHttpsRedirection();

        app.UseImageSharp();

        app.UseStaticFiles();

        app.UseCors();

        app.UseRouting();

        app.UseAuthorization();

        app.MapRazorPages();

        app.Run();
    }
}

[account00001]

I wrapped ImageSharp up in my own wrapper, the app.Environment is residual from that and has been removed. Sorry for the confusion.

As far as the reproduction example, I don't think that would reproduce it because you are on the same origin. The issue arises when you attempt a cross origin request (UI is on port A and API is on port B).

[account00001]

Setup

Add an image called "image.png" to your desktop.

In the "frontend" directory, run npm install then npm run serve. This assumes you have NPM And NodeJS installed.

In the "backend" directory, simply hit the play button in Visual Studio with "Api" as your startup project.

Frontend

Visit https://localhost:8080/ to load "image.png" from the frontend (UI, port 8080).


Notice we are on port 8080 making a request to 7227. Cross origin.

Backend

Visit https://localhost:7227/api/image to load "image.png" from the backend (API, port 7227).


We are on 7227 making a request to 7227. Ok.

Reproduction

With lines 31-37 commented out in Program.cs, relaunch the Api project and the CORS error occurs (request is blocked).

            builder.Services.AddImageSharp(options =>
            {
                //options.OnPrepareResponseAsync = (context) =>
                //{
                //    context.Response.Headers.AccessControlAllowOrigin = new("https://localhost:8080");
                //    context.Response.Headers.AccessControlAllowHeaders = new(new[] { "content-type", "cache-control" });
                //    context.Response.Headers.AccessControlAllowMethods = new("GET");
                //    return Task.FromResult(context.Response);
                //};
            })

Files

Here is the complete example.

ImageSharp.Web-discussions-291.zip

[JimBobSquarePants]

Thanks for this. It made it nice and easy to replicate the issue!

I have a fix in the works which will apply the correct policy automatically.

[account00001]

Adding to this, I think there may be a more complex issue afoot. I've been seeing odd caching behavior, even after disabling all the cache and using a NullImageCache with SetCache. Completely disabling ImageSharp fixes the caching issue. I've managed to trace it back to relating to CORS.

The CORS preflight request sends an OPTIONS request to the backend and it should respond with a 204 No Content. Then it sends the GET request to the same endpoint to retrieve the content.

What I'm seeing is the preflight OPTIONS request return a 200 with some content. Later, the GET request also returns a 200 with some content.

These two requests are hitting the same endpoint with the same image ID and should be returning the same image, however both the OPTIONS and the GET are returning a random image (the image isn't even consistent between the same request, meaning both the preflight and the actual request can be different images while attempting to retrieve the same ID, plus preflight shouldn't return anything to begin with).

When I access the image directly from the backend it is always correct.

I'm not sure why the OPTIONS is returning actual content, but I think it's throwing something off when the actual GET request is sent. I think part of respecting the CORS policy should also include appropriate handling for OPTIONS requests, as right now it seems it's not looking at the request method before returning a response. As far as it returning a random image even with all cache disabled, I have no idea. It probably returns a random image like 30% of the time.

I'm not really sure where to go from here, I suppose I'll have to disable ImageSharp until I can test the CORS fix and see if it also fixes this issue. Please let me know when the fix is ready, I'd be interested in helping test it.

[JimBobSquarePants]

These symptoms are unlike anything I have ever heard and the middleware is used on thousands of sites serving millions of images. With the default hashing strategy in place collision opportunities are 1 in 10s of millions.

I haven’t forgotten about the CORS fix. I have local code that returns the correct response I’m just not sure whether the middleware is the best place to do so. Normally CORS behaviours are configured against individual endpoints in the routing configuration.

[account00001]

Good news, I managed to track down the root issue being bad async code inside the image provider. Now that that's fixed, I no longer get random images. This was positively interfering with the caching behavior on top of the preflight issue, causing some red herrings. Bad news is the CORS issue where the preflight returns a 200 with a response is still a true bug, however much less severe (unless resources/bandwidth are important). I expect that should be an easy fix, to just check the method on the request before going through the rest of the pipeline. I can give you an example project which reproduces that if needed.