Conversation
5226a58 to
d6e3a59
Compare
|
What do you think about having a CSP Reporter Service? for receiving CSP violations from browsers? The THttpHeadersManager could have a bool|string flag with true/false/Auto that installs the TCSPReporterService. When the "report-to" (and "report-uri") policy/directive is present, "Auto" adds the service. true always installs the CSP Reporter Service regardless of using "report-to". It may help to debug CSP violations as they occur. The TCSPReporterService should log the report and trigger its "on" event for handling the error. It should have a static method for retrieving the application TCSPReporterService if it's available; so modules-etc can easily install an event handler on a CSP Report. Also, part of page lockdown process of CSP is "integrity" for external JS and style. I've already put a shell script into the prado-dev-tools for looking at local and remote files and getting their SHA hash for "integrity". The issue is that stylesheets would also need a wrapper like TJavascriptAsset and to centralize the stylesheet render. |
|
I think this is a really good idea. I especially like the part about the "on" event, it makes it very flexible 👍 |
|
The expanded version of this requires a few positive changes to the framework.
This brings up a really good point: THttpResponse is the primary "source of truth" regarding headers. THttpHeaderManager is a secondary process. It makes sense to establish THttpHeaderManager as the main centralized point for headers, and maybe cookies. This may be worth investigating after this PR. |
… methods While working on this, a bug in TFirebugLogRoute has been found and fixed (missing log render on postbacks)
…t inside THttpResponse
This branch will contain work to implement support for Content Security Policy (#1004)
The PR will ensure code is tested while working on it
By now the following steps has been committed:
<script>tag rendering in a single place