Not sure how tests are run, I keep getting this error:

 FAIL  test/unit/permissions.test.ts
  ● Test suite failed to run

    TypeError: Converting circular structure to JSON
        --> starting at object with constructor 'Serverless'
        |     property 'yamlParser' -> object with constructor 'YamlParser'
        --- property 'serverless' closes the circle
        at stringify (<anonymous>)

      at messageParent (node_modules/jest-worker/build/workers/messageParent.js:34:19)

Thanks for the PR!

Yeah unfortunately tests are broken on master because of changes in serverless framework, haven't found time (or even have an idea) to fix it :/

Use 403/404 error responses to replace the request function

Could you explain this? I'm not sure what the impact is? Will the application behave any differently?

Use response headers policy to replace the response function

Are the same exact security headers added? I.e. are there any practical changes for applications already deployed with Lift?

@mnapoli No worries.

Use 403/404 error responses to replace the request function

Could you explain this? I'm not sure what the impact is? Will the application behave any differently?

SPAs need their origin paths rewritten to /index.html to load the entry point, Lift currently uses a CloudFront function to redirect any paths not ending in a whitelisted extension.

While this works, the function is not necessary - by setting the custom error responses for 404 (not found) and 403 (unauthorized, S3 returns one if the file doesn't exist and s3:ListBucket isn't allowed) we can redirect these to the entry point too.

Use response headers policy to replace the response function

Are the same exact security headers added? I.e. are there any practical changes for applications already deployed with Lift?

Here are the new headers (also linked in docs):

And here are the old headers:

So it is slightly different: mainly adding the Referrer-Policy.

I didn't retain the option to remove x-frame-options (security.allowIframe) as folks should use the new responseHeadersPolicy key to create a custom policy with securityHeadersBehavior.contentSecurityPolicy instead - for security, instead of allowing all iframes. I could add it back for backward compatibility, though it might be easier to use custom policies if we keep it.

FYI - this build was tested with a SPA and Serverless deployment.