Provide a README

@himanshu_jhaloya Please explain your changes, and why are you opening a new merge request instead of working on the existing one? You added a quickedit dependency, which as far as I know is not necessary.

Unassigning, and I recommend not providing contribution credit to @himanshu_jhaloya.

Just looking into some site improvements, including adding modern CSP policy header recommendations, and would also love some basic descriptions and potentially suggestions for setting this up for sites.

ravi kant → made their first commit to this issue’s fork.

ravi kant → changed the visibility of the branch 8.x-1.x to hidden.

@W01F
I have updated MR !9 according README Template → Standard.

Also hiding MR !10 due to it have extra file which is not required to add in this ticket.

I haven't coalesced my thoughts about what information is relevant for each of the project page, readme, and documentation pages (personally, I don't think just copying the project page to a readme file is useful, and I think there's few things that should be in a readme that aren't also worth having on the project page).

Generic recommendations are kind of difficult, since build practices, modules used, third-party services, whether CSP is being added to a new or existing project, and developer knowledge vary so much.

The MDN web docs are a good resource on the available directives, and has some recommendations, but isn't necessarily beginner friendly
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Securi...

Two approaches to configuring a policy:

1. Set the strictest possible report-only policy (e.g. default-src 'none'; script-src 'self'; style-src 'self'; img-src 'self'), and then selectively allow sources as needed based on the violation reports after browsing around your site. Either do not set a reporting handler so you don't spam/DOS your own site log (and then check the violations in your browser console), or use Report-URI.com's wizard to ingest and summarize the reports. Deploy your report-only policy to staging/production, monitor for violations, and adjust. Once you're not receiving violation reports, promote your policy to enforced.

   I think this approach may be more suited for new sites, were problems on staging / pre-production are likely to be found by devs and testers, and not site users.

2. Start with a very lenient policy and incrementally narrow restrictions on your report-only policy. Monitor small changes for violations (in staging and then production) and adjust before promoting to enforced. This is sort of the approach the module's default configuration takes: the enforced policy is rather lenient, but if the report-only policy doesn't result in violations in can be promoted. A directive like font-src is one that's usually pretty easy to add to a policy to restrict loading to only your chosen font service, but can't be included in the module's default policy.

   I think this approach is more suited for established sites, where prematurely enforcing a policy could result in breaking existing functionality for site users. (New functionality breaking because a needed adjustment to the enforced policy is not deployed at the same time, I think is less significant concern - and testing should probably catch issues before that happens).

📌 Improve default config Active has some philosophy behind the module's default configuration and some options being considered for 2.0.0 that I would appreciate feedback on.

If you have specific questions on getting started with CSP, feel free to ping me on the drupal slack - either privately or start a thread in the #security-discussion channel. I really value learning about other people's implementations so I can eventually work on a guide to help others get started!