├── meetings ├── README.md ├── 2025-01-06-minutes.md ├── 2025-04-14-minutes.md ├── 2024-12-16-minutes.md ├── 2025-02-10-minutes.md ├── 2025-10-13-minutes.md ├── 2025-07-14-minutes.md ├── 2024-11-11-minutes.md ├── 2025-06-09-minutes.md ├── 2025-08-11-minutes.md ├── 2025-07-07-minutes.md ├── 2025-01-27-minutes.md ├── 2024-11-25-minutes.md ├── 2025-03-24-minutes.md ├── 2025-05-19-agenda.md ├── 2025-02-17-minutes.md ├── 2025-03-31-minutes.md ├── 2024-11-18-minutes.md ├── 2025-04-28-minutes.md ├── 2025-10-06-minutes.md ├── 2024-08-12-minutes.md ├── 2025-05-04-minutes.md ├── 2025-04-07-minutes.md ├── 2024-09-16-minutes.md ├── 2024-10-28-minutes.md ├── 2025-08-04-minutes.md ├── 2024-08-26-minutes.md ├── 2025-02-24-minutes.md ├── 2025-09-08-minutes.md ├── 2025-07-28-minutes.md ├── 2024-07-08-minutes.md ├── 2025-03-10-minutes.md ├── 2025-06-16-minutes.md ├── 2025-09-15-minutes.md ├── 2024-10-07-minutes.md ├── 2024-10-21-minutes.md ├── 2025-05-12-minutes.md ├── 2024-08-05-minutes.md ├── 2024-12-09-minutes.md ├── 2024-07-29-minutes.md ├── 2025-08-25-minutes.md ├── 2025-09-29-minutes.md ├── 2024-06-28-minutes.md ├── 2024-07-01-minutes.md ├── 2025-01-13-minutes.md ├── 2024-09-09-minutes.md └── 2024-07-22-minutes.md ├── w3c.json ├── CODE_OF_CONDUCT.md ├── LICENSE.md ├── CONTRIBUTING.md ├── README.md └── docs ├── regulatory_policy.md ├── guidelines_for_libraries.md └── security_guidelines.md /meetings/README.md: -------------------------------------------------------------------------------- 1 | Repo for meeting agendas and minutes docs. 2 | -------------------------------------------------------------------------------- /w3c.json: -------------------------------------------------------------------------------- 1 | { 2 | "group": [157132] 3 | , "contacts": ["simoneonofri"] 4 | , "repo-type": "cg-report" 5 | } 6 | -------------------------------------------------------------------------------- /CODE_OF_CONDUCT.md: -------------------------------------------------------------------------------- 1 | # Code of Conduct 2 | 3 | All documentation, code, communication and discussion in this repository are covered by the [W3C Code of Conduct](https://www.w3.org/policies/code-of-conduct/). 4 | -------------------------------------------------------------------------------- /LICENSE.md: -------------------------------------------------------------------------------- 1 | All Reports in this Repository are licensed by Contributors 2 | under the 3 | [W3C Software and Document License](https://www.w3.org/copyright/software-license/). 4 | 5 | Contributions to Specifications are made under the 6 | [W3C CLA](https://www.w3.org/community/about/agreements/cla/). 7 | 8 | Contributions to Test Suites are made under the 9 | [W3C 3-clause BSD License](https://www.w3.org/copyright/3-clause-bsd-license-2008/) 10 | 11 | -------------------------------------------------------------------------------- /meetings/2025-01-06-minutes.md: -------------------------------------------------------------------------------- 1 | # SWAG CG Minutes 6 Jan 2025 2 | 3 | Present: Dan, Will, Aaron 4 | 5 | ## Videos 6 | 7 | The videos are ready. They need to go out this week... 8 | 9 | ## Contribution 10 | 11 | Aaron: going to find some text around CSP and trusted type support - and see if we can seed the draft document (on libraries)... 12 | 13 | *we discuss security guidelines* 14 | 15 | Will: Some CSP material. I also landed the XSS guide into MDN... I could work on adapting some of that... And clickjacking... 16 | 17 | Dan: Will do some recruitment - and also work with OpenSSF and OpenJS 18 | 19 | Will: working on cross-site links ... COOP, COEP, etc... guide... 20 | 21 | -------------------------------------------------------------------------------- /meetings/2025-04-14-minutes.md: -------------------------------------------------------------------------------- 1 | # SWAG CG Minutes - Mon 14 April 2025 2 | 3 | Present: Simone, Will 4 | 5 | ## Survey 6 | 7 | - very draft document: https://docs.google.com/document/d/1K2ofj5JgCDgIg5-xZTFMwYXms7KXoiid-e0QucUeGyc/edit?tab=t.0#heading=h.tw1uogg9w4to - needs work, but to give an idea of the kind of questions we want answers to. 8 | 9 | - Simone has a contact who's a web developer at the UN and might be amenable to an interview. Once we have better questions let's ask them. 10 | 11 | - Florian has started talking to Kadir about logistics of how to find participants and how to run a user interview. Florian will schedule a call about it. 12 | 13 | ## AOB 14 | 15 | Since there were just the two of us in the meeting, we can take up any other issues in the Slack channel. 16 | -------------------------------------------------------------------------------- /CONTRIBUTING.md: -------------------------------------------------------------------------------- 1 | # Security Web Application Guidelines Community Group 2 | 3 | This repository is being used for work in the W3C Security Web Application Guidelines Community Group, governed by the [W3C Community License 4 | Agreement (CLA)](http://www.w3.org/community/about/agreements/cla/). To make substantive contributions, 5 | you must join the CG. 6 | 7 | If you are not the sole contributor to a contribution (pull request), please identify all 8 | contributors in the pull request comment. 9 | 10 | To add a contributor (other than yourself, that's automatic), mark them one per line as follows: 11 | 12 | ``` 13 | +@github_username 14 | ``` 15 | 16 | If you added a contributor by mistake, you can remove them in a comment with: 17 | 18 | ``` 19 | -@github_username 20 | ``` 21 | 22 | If you are making a pull request on behalf of someone else but you had no part in designing the 23 | feature, you can remove yourself with the above syntax. 24 | -------------------------------------------------------------------------------- /meetings/2024-12-16-minutes.md: -------------------------------------------------------------------------------- 1 | # SWAG CG Call - Mon 16 December 2024 2 | 3 | Present: Dan, Will 4 | 5 | ## OpenSSF / LF Europe Cybersecurity Workshop 6 | 7 | https://events.linuxfoundation.org/open-source-software-stewards-manufacturers-workshop/ 8 | 9 | Dan: Websites are apparently exempt from the CRA but packaged web apps (e.g. electron apps) do count as "products with a digital element" so are counted under the act. Lots to talk about here - anr relevant to the libraries guidelines discussion. 10 | 11 | ## Libraries Guidelines 12 | 13 | Will: Will be working on this shortly. 14 | 15 | ## XSS GUide page on MDN 16 | 17 | Will: working on this https://github.com/mdn/content/pull/36412 - and would like to get more technical reviews... 18 | 19 | *we discuss those who might be invited to give a technical review* 20 | 21 | ## Call schedule 22 | 23 | Dan: I will re-up the regular calls at this time for next year but we will start on the 6th of Jan. 24 | -------------------------------------------------------------------------------- /meetings/2025-02-10-minutes.md: -------------------------------------------------------------------------------- 1 | # SWAG Minutes - Mon 10 February 2025 2 | 3 | - Present: Dan, Will 4 | - Regrets: Lola, Aaron 5 | 6 | ## PR review 7 | 8 | Looking at PR https://github.com/w3c-cg/swag/pull/12 to expand on HTTPS guideline. 9 | 10 | - should we have more resources than just Mozilla's, on TLS config? Perhaps but not a blocker for this PR, can add it later. 11 | - should we justify recommendation using something like https://www.w3.org/2001/tag/doc/web-https ? 12 | 13 | **we agree to merge** 14 | 15 | ## Limit use of 3rd party script... 16 | 17 | Will: in security guidelines doc the title is "Limit the use of third-party scripts and resources" but the body is all about using SRA... the title is not matching the content. 18 | 19 | ...Also a guideline on CSRF... I want to write a page on MDN about it.. I'm drafting a page on MDN on CSRF.. that will feed into a guideline. 20 | 21 | PR to MDN on sanitizing user input... How we could do better on MDN ... 22 | 23 | Trusted Types PR: https://github.com/mdn/content/pull/37917 is in review 24 | 25 | ## SWAG at SOSS COmmunity Day 26 | 27 | CFP open - june 23, 2025 in Denver: https://openssf.org/blog/2025/01/29/openssf-community-day-na-2025-call-for-proposals-now-open/ 28 | 29 | -------------------------------------------------------------------------------- /meetings/2025-10-13-minutes.md: -------------------------------------------------------------------------------- 1 | # SWAG CG Minutes - Mon 13 October 2025 2 | 3 | Present: Florian, Dan, Simone, Aaron 4 | 5 | Regrets: Will 6 | 7 | ## Prototype polution 8 | 9 | Florian: I've received many reviews... Also people from Mozilla seem to be happy with it. 10 | 11 | ... hope to merge tomorrow. 12 | 13 | ## Supply Chain Attacks 14 | 15 | https://github.com/mdn/content/pull/41034 Merged and live! 16 | 17 | https://developer.mozilla.org/en-US/docs/Web/Security/Attacks/Supply_chain_attacks 18 | 19 | Dan: next step on this is to figure out what summary we can put into our document... 20 | 21 | Florian: Defense summary check-list ... we've written 3 or 5 articles... we haven't integrated back all the guidelines to ths SWAG guidelines. Also on prototype pollution. 22 | 23 | Aaron: Please take a look at some of the other potential soruces for check-lists, portswigger, web.dev also other sites... 24 | 25 | Florian: then in a next SWAG call we can go through the doc 26 | 27 | Dan: in the context of reviewing the PR 28 | 29 | ## Survey 30 | 31 | No update this week. 32 | 33 | Florian: on MDN they've launched another survey... 34 | 35 | ## Authentication 36 | 37 | Florian: will be working on this thus week... 38 | 39 | 40 | 41 | -------------------------------------------------------------------------------- /meetings/2025-07-14-minutes.md: -------------------------------------------------------------------------------- 1 | # SWAG Minutes - Mon 14 July 2025 2 | 3 | Present: Simone, Dan, Aaron 4 | 5 | ## Regulatory document 6 | 7 | https://github.com/w3c-cg/swag/blob/main/docs/regulatory_policy.md - 8 | 9 | From Dan's problem motivation slides: Boundaries between web application and more native applications (i.e. mobile) and apps that cause real-world effects (i.e. smart home) are very blurred-- and hence the security standards need to be higher. For instance-- use libraries that have been vetted. 10 | 11 | Dan is looking for feedback on the draft doc. Do not need to be lawyer because we are explicitly not giving legal advice. 12 | 13 | ## Survey 14 | 15 | Going through each of the survey comments. https://docs.google.com/document/d/1K2ofj5JgCDgIg5-xZTFMwYXms7KXoiid-e0QucUeGyc/edit?pli=1&tab=t.0#heading=h.b8o6rwyukyw7 16 | 17 | Do we want to keep descriptions around what each of the mitigations we ask about? Or just name them and ask? 18 | 19 | *we go through and approve many changes to the doc* 20 | 21 | *discussion on libraries and frameworks* 22 | 23 | *we merge all cookies questions* 24 | 25 | *we agree to move forward on this...* 26 | 27 | ## Discussion on Threat Modeling for the Web 28 | 29 | Simone: we need to add human rights threats.. considering human rights threat... 30 | -------------------------------------------------------------------------------- /meetings/2024-11-11-minutes.md: -------------------------------------------------------------------------------- 1 | # SWAG CG Minutes - Mon 11 November 2024 2 | 3 | Present: Dan, Siyhhmone, Aaron 4 | 5 | ## General Topics 6 | 7 | Dan: Spoke at Dev Con Bucharast last week... 8 | 9 | Simone: Demographics of web developers ... https://stateofhtml.com/en-US ... 10 | 11 | 12 | 13 | ## Next week's call 14 | 15 | Aaron - to do a talk on XSS Mitigations - tools-based approach to mitigating XSS. A lot of academic studies on why it's difficult to adopt trusted types and CSP and other technologies to resist XSS. So how can we provide some tooling - semi-automnated tooling to skew developers in the right direction - e.g. CSP Evaluator, Trusted types helper extension, Safety-Web (developer-side tooling) e.g. code scanner that detects problems in code. Next steps: introducing APIs that nudge developers towards safe practices - e.g. "safevalues". 16 | 17 | Dan: We'll do that on the 18th and I'll blast it out to some additional channels... We'll do it on zoom and record it. 18 | 19 | ## CSP changes in MDN 20 | 21 | Dan: Open Web Docs post: https://front-end.social/@openwebdocs/113463902238518683 22 | 23 | Simone: *will ping WebAppSec* 24 | 25 | Dan: and let's get the word out about this... 26 | 27 | ## Guidelines for Library Developers 28 | 29 | Dan: https://github.com/w3c-cg/swag/blob/main/docs/guidelines_for_libraries.md we need to kick-start it... 30 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | This is the repository for the [SWAG Community Group](https://www.w3.org/community/swag/). This group is run as an open community and is coordinating with other industry bodies including [OpenSSF](https://openssf.org), [OWASP](https://owasp.org) and the [Open JS Foundation](http://openjsf.org). The work of this group stems from the [output of the Secure the Web Forward workshop](https://www.w3.org/2023/03/secure-the-web-forward/report.html). 2 | 3 | Our current working documents are: 4 | * [Guidelines for developing more secure web applications](https://github.com/w3c-cg/swag/blob/main/docs/security_guidelines.md) 5 | * [Security Guidelines for Framework & Library Developers](https://github.com/w3c-cg/swag/blob/main/docs/guidelines_for_libraries.md) 6 | 7 | This group is open to anyone to join. If you would like to join, please visit [this page](https://www.w3.org/community/swag/join). You will be asked to create a W3C account if you do not have one already. If you are affiliated with a [W3C Member organization](https://www.w3.org/membership/list/) then you will have to ask your Advisory Committee represenative to add you to the group. 8 | 9 | We are using the [W3C Community Slack](https://w3ccommunity.slack.com/archives/C079JKV32RX) to organize and do work asynchronously between meetings. Our minutes are [posted in this repo](https://github.com/w3c-cg/swag/tree/main/meetings) after every call. 10 | -------------------------------------------------------------------------------- /meetings/2025-06-09-minutes.md: -------------------------------------------------------------------------------- 1 | # SWAG Minutes - Mon 9 June 2025 2 | 3 | Present: Dan, Will, Aaron 4 | 5 | ## Dan's talks 6 | 7 | Talking at OpenSSF Community Days NA in Denver in June and Europe in Amsterdam in August... What should be the calls to action? 8 | 9 | Will: we don't want security professionals to answer the survey - we want web developers... so not sure that's the call to action... 10 | 11 | ## Survey 12 | 13 | draft: https://docs.google.com/document/d/1K2ofj5JgCDgIg5-xZTFMwYXms7KXoiid-e0QucUeGyc/edit?tab=t.0 14 | 15 | Good feedback so far... added a bunch of stuff.. looks somewhat massive... We need more feedback from group members..... Let's put it on the Slack. 16 | 17 | Aaron: working on a google blog post on external work including work of this group - so can include the call to action on the survey there... 18 | 19 | ## Regulatory Policy Doc 20 | 21 | https://github.com/w3c-cg/swag/pull/25 22 | 23 | Dan: I will make another pass at this and then send review requests to all... 24 | 25 | ## Guidelines... 26 | 27 | Will: been thinking about MDN docs and MDN security docs... started a proposal for reorg of MDN security documentation... no feedback so far ... except from Hamish... https://github.com/orgs/mdn/discussions/802 Written a bunch of pages on different attacks... a lot of defenses work across multiple attacks... e.g. same site cookies are a response to CSRF and clickjacking... 28 | 29 | -------------------------------------------------------------------------------- /meetings/2025-08-11-minutes.md: -------------------------------------------------------------------------------- 1 | # SWAG Minutes - Mon 11 August 2025 2 | 3 | Present: Dan, Giovanni, William, Simone 4 | 5 | ## Survey 6 | 7 | Will: got feedback from MDN on surveys... 2 guidelines - one is collecting info from people - is it OK to ask for peoples' email addresses... other thing is survey length (3-5 questions). For the email address thing I've ask for clarification... Other question on length... I didn't get an answer... Might be better to use MDN as a funnel... One question survey... 8 | 9 | Simone: from a gdpr perspective... the agreement is often between the user and the web site that is exposing the question... if it's MDN then Mozilla is the party... There should also be an agreement between them and W3C... 10 | 11 | Dan: ... injects uncertainty and angst... 12 | 13 | Simone: we can try to make it simple ... but we can sat "email address.. but we only will use it to contact you... and nothing else.... We're using the data only for that reason." 14 | 15 | Will: that sounds reasonable... In practice we would have MDN mozilla ... someone responsible at Mozilla has to agree that this is an appropriate course to take. 16 | 17 | Simone: I can also ask legal at W3C... 18 | 19 | Dan: maybe MDN would help us run the survey... even if it's not their survey. 20 | 21 | Will: a "banner" - that's what we're asking them to do... It's something I can follow up with... 22 | 23 | Will: in background, working on supply chain attacks... 24 | 25 | -------------------------------------------------------------------------------- /meetings/2025-07-07-minutes.md: -------------------------------------------------------------------------------- 1 | # SWAG Minutes - Mon 7 July 2025 2 | 3 | Present: Dan, Simone, Giovanni, Aaron 4 | Regrets: Will 5 | 6 | ## Off-topic discussion on Digital Credentials 7 | 8 | https://www.w3.org/blog/2025/w3c-digital-credentials-api-publication-the-next-step-to-privacy-preserving-identities-on-the-web/ 9 | 10 | ## Survey Content 11 | 12 | Aaron: How long should we run these surveys for? 13 | 14 | Dan: A couple months the last time. Try to run for July-Aug and then take action in September. 15 | 16 | Simone: July-Aug might be holidays. 17 | 18 | Dan: Good time to answer surveys! 19 | 20 | Aaron: I can plug it at conference I'll be at... get more eyes on it... We can add a link to this survey to a blog post... 21 | 22 | Dan: I can work to get something out on the Samsung Internet blog as well... 23 | 24 | Dan: Current review of the doc together. 25 | 26 | Aaron: https://bughunters.google.com/blog/6644316274294784/secure-by-design-google-s-blueprint-for-a-high-assurance-web-framework Comaring - a couple of things are missing... some are google-specific. Secure attribute on cookies - we take it seriously. 27 | 28 | Simone: yes - https security headers... we can use this survey to understand why ... we know , but we don't know why... 29 | 30 | ... discussion on what additional info we should collect - e.g. what role do they play, any demographic info? ... 31 | 32 | Simone: do we want a top 10 vulnerabilities from web developers? If we have a top 10 or top 5 features from responses from this survery we could publish that... 33 | 34 | -------------------------------------------------------------------------------- /meetings/2025-01-27-minutes.md: -------------------------------------------------------------------------------- 1 | # SWAG Miunutes - Mon 27 2 | 3 | Present: Dan, Simon, Simone, lola, Will 4 | 5 | ## [PR on the guidelines doc](https://github.com/w3c-cg/swag/pull/8) 6 | 7 | Will: filed this - at the moment it's written like a list - and each is a list item. I think that won't scale well. This is mostly a formatting change. 8 | 9 | **MERGED** 10 | 11 | ## CSP addition & other 12 | 13 | Will: will work more on CSP... there is an open issue - should we recommend strict CSP ? I'll close that issue with this addition... 14 | 15 | Will: some guidelines on authentication -- feels like a category. Big-scale thing. Other: secure cookie settings (what cookie attributes to set); 16 | 17 | Dan: partitioned cookies is another area... where we really need to provide guidance. 18 | 19 | Lola: on MDN there is info on securing storage access API.. should we say something about that as well? 20 | 21 | Dan: link off to detailed info... 22 | 23 | Will: on storage access.. a lot of web APIs have rules... e.g. secure contexts... these aren't such a problem because as a developer you can't cause problems ... 24 | 25 | *some discussion on level of detail...* 26 | 27 | Will: e.g. on CSP we want basic guidelines - use CSP, use stict CSP and here are the details on that... 28 | 29 | Simon: cors and coep and cross origin opener policy... an especially unpleasant situation where many of the things people want to do won't work in practice. 30 | 31 | Will: yes we should have a guideline ... also on that topic we should have 32 | 33 | Will: other things: sanitizers, output encoding, etc... 34 | 35 | ## Videos 36 | 37 | *we will try to get the videos out starting this week* 38 | 39 | -------------------------------------------------------------------------------- /meetings/2024-11-25-minutes.md: -------------------------------------------------------------------------------- 1 | # SWAG CG Minutes - Mon 25 November 2024 2 | 3 | Attendees: Dan, Benjamine, Aaron, Will, Simone, Estelle 4 | 5 | ## New Friends 6 | 7 | Benjamine: working for Capital One... 8 | 9 | ## Videos for last week's call 10 | 11 | Simone: I need all the email addresses for the participants... 12 | 13 | *Aaron to provide* 14 | 15 | ## Follow-ups from last week 16 | 17 | Dan: I'd like to start going on https://github.com/w3c-cg/swag/blob/main/docs/guidelines_for_libraries.md 18 | 19 | Aaron: Is this more like a checklist of properties that we officially think a library developer should follow? Or just a grab-bag of useful techniques, etc? 20 | 21 | Dan: it's a set of guidelines - not strict conformance requirements... 22 | 23 | Aaron: If it's just a collection of guidelines/techniques, we are ready to start talking about specific topics e.g. Dom XSS mitigations ... 24 | 25 | Aaron: an avenue to surface ... data from scans ... Maybe a github repo that is the outputs of these scans... Is there some UX that we can work together on under the W3C umbrella or something in conjunction with OpenSSF to make it more visible to developers? 26 | 27 | ### Trusted Types Documentation 28 | 29 | Will: we need better docs on Trusted Types on MDN... the time for that is when it gets cross browser support... I can help with that. Right now there is API docs on MDN but not guidance... 30 | 31 | Dan: it would be good to know when it will be added to baseline. 32 | 33 | Aaron: we have a web.dev article... but if there is more material... we can share, let me know. 34 | 35 | # W3C Security Interest Group 36 | 37 | Simone: I'll be sending the announcement soon. We need to synchronize on the "web threat model" - this will guide all the web developments... Threat model will be developed in the Interest group - with coordination with SWAG... I will be one of the editors but feel free to propose one if you like... 38 | -------------------------------------------------------------------------------- /meetings/2025-03-24-minutes.md: -------------------------------------------------------------------------------- 1 | # SWAG CG Minutes - Mon 24 March 2025 2 | 3 | Present: Will, Aaron 4 | 5 | ## Open PRs 6 | 7 | https://github.com/w3c-cg/swag/pulls 8 | 9 | - samesite guideline 10 | - framing protection guideline 11 | 12 | ...please review 13 | 14 | ## Open issues 15 | 16 | https://github.com/w3c-cg/swag/issues 17 | 18 | - fetch metadata guideline 19 | 20 | ## MDN docs updates 21 | 22 | - CSRF doc published: https://developer.mozilla.org/en-US/docs/Web/Security/Attacks/CSRF, thanks to mozfreddyb for reviews 23 | 24 | - XS-leaks doc will be out for review this week 25 | 26 | - Aaron will find a colleague to review 27 | - ensure MDN and xsleaks.dev are aligned 28 | 29 | - consider a guide to fetch metadata on MDN? 30 | - xsleaks.dev and web.dev already has good content. Do we need something on MDN as well? If we do, make sure it's aligned with xsleaks.dev 31 | 32 | ## Remaining work on attacks for MDN 33 | 34 | Which other attacks need documentation at https://developer.mozilla.org/en-US/docs/Web/Security/Attacks? 35 | 36 | - supply chain? 37 | - Mitm? 38 | - ...any more? 39 | 40 | Discussion: 41 | 42 | - it is worth documenting Mitm even though it could be seen as a solved problem. 43 | - after supply chain and Mitm we can say we are done with documenting attacks on MDN: Google's view is that the main areas needing devs' attention are injection (XSS) and isolation (XS-leaks), and we will have coverage for those. 44 | 45 | ## Google blog posts 46 | 47 | - https://bughunters.google.com/blog/5850786553528320/a-deep-dive-into-js-trusted-types-violations 48 | - https://bughunters.google.com/blog/6644316274294784/secure-by-design-google-s-blueprint-for-a-high-assurance-web-framework 49 | - promote these docs and/or incorporate them into other sources 50 | - link them from SWAG guidelines 51 | 52 | - how can google help disseminate SWAG work? Aaron + colleagues speaking at [BSides Seattle](https://www.bsidesseattle.com/) in mid-April -- is there a brief call out to the work that this CG is doing and a brief call to action for the audience? 53 | -------------------------------------------------------------------------------- /meetings/2025-05-19-agenda.md: -------------------------------------------------------------------------------- 1 | # W3C SWAG Minutes - Mon 19 May 2025 2 | 3 | Present: Dan, Martina, Aaron, Simone 4 | 5 | ## Regulatory & Policy First Stab 6 | 7 | https://github.com/w3c-cg/swag/pull/25 8 | 9 | Dan: this is a draft that tries to get across the key points specifically focusing on CRA 10 | 11 | Martina: Is CRA also dependent on the countries and how they are implementing it? 12 | 13 | Dan: yes but I think it's not so relevant to web developers 14 | 15 | Dan: the PR is in draft - let's contimue to work on it in Draft and then we can try to merge by next meeting? 16 | 17 | ## Survey of Web Developers 18 | 19 | Dan: any chance to talk to Dom? 20 | 21 | Simone: Plan for survey: 22 | 23 | > 1. Create an issue in the web-platform-dx/developer-research repository, along the lines of: 24 | https://github.com/web-platform-dx/developer-research/issues/19 25 | (If the goal is to re-run the survey, the new issue should typically link to that one!). 26 | > 2. Come and present the idea at an upcoming WebDX CG meeting (every other Thursday at 3pm UTC, next one on 29 May) to gather feedback on the survey and assess interest from MDN people. You may not get a lot of feedback, but at least people will be aware that this is upcoming. 27 | > 3. Work with Ruth (@Rumyra on GitHub) to run the survey on MDN and collect results. They may handle the survey as part of the mdn/short-surveys repository (but that repository is still private for the time being): 28 | https://github.com/mdn/short-surveys/discussions. 29 | > 4. Once the survey has run, gather raw results from Ruth, and prepare a PR against developer-research with the data and an interpretation, as done in: 30 | https://github.com/web-platform-dx/developer-research/tree/main/mdn-short-surveys/2023-05-15-security-dx. 31 | 32 | ## AOB 33 | 34 | Aaron: Use of company engineering blog -- security engineering blog -- very technical -- talking about projects that are building defenses. Can use as a way to get the word out about this group. Will tie together with other big open source ecosystem ... also a call to action: come join us in SWAG. 35 | 36 | 37 | 38 | 39 | 40 | 41 | 42 | 43 | -------------------------------------------------------------------------------- /meetings/2025-02-17-minutes.md: -------------------------------------------------------------------------------- 1 | # SWAG - Mon 17 February 2025 2 | 3 | Present: Aaron, Simone, Simon, Lola, Dan 4 | Regrets: Will 5 | 6 | ## Threat Modeling work in SING 7 | 8 | Simone: will be starting a deliverable of the Security interest group around threat modeling - i will be asking everyone in this group for feedback on this. 9 | 10 | ... not a lot RFC 3552. 11 | 12 | RFC-3552 - explains how to write security consierations... 13 | 14 | people often don't follow this approach. They might need more guidance... 15 | 16 | Lola: what other group will you reac out to? 17 | 18 | Simone: other working groups ... e.g. verifiable credentials working group .. other discussions ... developers of vibration API... also fedID working group. A work in progress. 19 | 20 | Lola: It would be worth also speaking to the WebDX group ... developer documentation ... e.g. MDN work ... but also surveys ... e.g. HTML, CSS, JS surveys... I can bring it up on our next meeting on Thursday. 21 | 22 | Dan: also please engage with the TAG 23 | 24 | ## Libraries Document 25 | 26 | Aaron: how do we want to link out to external resources? We could link to technical blog posts... compability with trusted types... resources other than MDN... 27 | 28 | Dan: somewhat concerned about fragility of URLs... but wouldn't rule it out .. needs to be evaluated on a case-by-case... 29 | 30 | Aaron: e.g. google bughunters blog... 31 | 32 | Dan: we need balance... 33 | 34 | Aaron: for instance with publication of videos for call in November .. is that something we should be linking to and mentioning in posts on google engineering blog. 35 | 36 | Dan: +1 37 | 38 | Simone: +1 - also one of my tasks is to publish the blog post and I will do that this week. 39 | 40 | ## SOSS community day 41 | 42 | Dan: I will make a talk proposal for SOSS community day NA in late June. That means this time frame could be a good "milestone" to shoot for - for having relatively done versions of these documents. 43 | 44 | ## Social media presence 45 | 46 | Aaron: should we have a branded social media presence ... 47 | 48 | Dan: *takes action to talk to powers that be about putting out a note on W3C Devs social media channels* 49 | 50 | -------------------------------------------------------------------------------- /meetings/2025-03-31-minutes.md: -------------------------------------------------------------------------------- 1 | # SWAG Minutes - Mon 31 March 2025 2 | 3 | Present: Dan, Aaron, Simone, Will 4 | 5 | ## [PR17](https://github.com/w3c-cg/swag/pull/17) 6 | 7 | Will: I made some changes based on Aaron and Chris de Alma's feedback. 8 | 9 | Dan: I think we can merge 10 | 11 | Aaron: ... frame ancestors .. browsers who do not support csp 2 are very obsolete ... so we should discourage people from using browsers from the 2010s... 12 | 13 | Will: I don't see any downside... because of the way frame ancestors work... so that's the key thing for ne. 14 | 15 | Aaron: Agree with you... we are also trying to push for deprecation of unsafe and obsolete browsers... 16 | 17 | Dan: [evergreen TAG finding](https://www.w3.org/2001/tag/doc/evergreen-web/) 18 | 19 | Aaron: do we have a solution to gey people to upgrade... developers sometimes have the power to nudge user behavior with a minimum supported version 20 | 21 | Dan: we could call for obsolete browser support to be deprecated ... 22 | 23 | Dan: [creates issue](https://github.com/w3c-cg/swag/issues/20) 24 | 25 | **broad agreement to merge** 26 | 27 | ## Issues 28 | 29 | fetch metadata: https://github.com/w3c-cg/swag/issues/13 30 | 31 | Possible [defenses](https://xsleaks.dev/docs/defenses/isolation-policies/) that can be implemented using Fetch Metadata headers 32 | 33 | Will: I've been poking at this for CSRF... 34 | 35 | Simone: we can put it on the agenda for the next call... 36 | 37 | ## New Members 38 | 39 | We have new members but they haven't been onboarding. 40 | 41 | **ACTION: Dan: to update github page to point to the page explaining how to join.** 42 | 43 | ## Standardized Public Outreach 44 | 45 | Aaron and colleagues have a XSS talk at [BSides Seattle](https://www.bsidesseattle.com/), how can we do a callout to this group? 46 | 47 | Dan: Call to action is the guidelines documents-- have a look, see if it makes sense, and what other things do you feel need to be in there? Open an issue, write a PR... join the call! 48 | 49 | Simone: We need more web developers so that we can get more requirements 50 | 51 | ## XS-leaks page on MDN 52 | 53 | Still in progress, will hopefully get a draft out this week. 54 | 55 | -------------------------------------------------------------------------------- /meetings/2024-11-18-minutes.md: -------------------------------------------------------------------------------- 1 | # W3C SWAG Minutes - Mon 18 November 2024 2 | 3 | Attendees: 4 | 5 | - Dan Appelquist (various) 6 | - Simone Onofri (W3C) 7 | - Randall T. Vasquez (NVIDIA / ThunderStrike) 8 | - Guillaume Weghsteen (Google) 9 | - Kian Jamali (Google) 10 | - Aaron Shim (Google) 11 | - Will Bamberg (OWD) 12 | - Kian (Google) 13 | - Himanshu Anand (c/side) 14 | - Artur Janc (Google) 15 | - Craig Bester (c/side) 16 | 17 | # New Group - SING group launched 18 | 19 | Simone: main focus is to review specs and create a Threat Model for the Web, we'll have to coordinate between groups https://www.w3.org/groups/ig/security/ 20 | 21 | # Talk from Aaron, Kian and Guillaume (Google) on tooling 22 | 23 | *Aaron presenting "Adopting XSS Mitigations: A Tool-based Approach for CSP and Trusted Types"* 24 | 25 | Aaron: *discusses secure-by-design approach* 26 | 27 | Dan: Noting [CISA's Secure-by-design initiative](https://www.cisa.gov/securebydesign) 28 | 29 | Aaron: *presenting [CSP Evaluator](csp-evaluator.wighgoogle.com) (also a chrome extension)* 30 | 31 | Kian: *presenting TTHelper chrome extension* 32 | 33 | Dan: Noting positive signals from [Webkit](https://github.com/WebKit/standards-positions/issues/186) and [Mozilla](https://github.com/w3ctag/design-reviews/issues/198) on Trusted types... (and [positive TAG review](https://github.com/w3ctag/design-reviews/issues/198) from a while back) - however implementation in other browsers besides chrome is not complete right now. - also see https://developer.mozilla.org/en-US/docs/Web/API/Trusted_Types_API 34 | 35 | Guillaume: *presents on Safety-Web - static analysis tool implemented as an ESLint plugin* 36 | 37 | Dan: q+ on trusted types : (1) cross-platform story (2) if developers should not write the policies then does that indicate it's too complex for some developers / small dev teams? 38 | 39 | Aaron: (1) what is the most actionable UI for displaying mitigation suggestions (nudging) (2) The NPM Puzzle - both CSP and TT benefit from 3p dependencies that are compatible... (3) why is there traditionally a large gap between web developers and security knowledge 40 | 41 | Dan: q+ on point 2, maybe our "library guidelines" 42 | 43 | Will: q+ on safety-web default policy: might this end up being part of the web platform? 44 | -------------------------------------------------------------------------------- /meetings/2025-04-28-minutes.md: -------------------------------------------------------------------------------- 1 | # SWAG CG Minutes - Mon 28 April 2025 2 | 3 | Present: Aaron, Will 4 | 5 | ## Meeting Link 6 | 7 | Source of truth is at https://www.w3.org/groups/cg/swag/calendar/. Meet link seems to be staying consistent for now at https://meet.google.com/stw-nqxg-kqw 8 | 9 | ## XS-leaks guide on MDN 10 | 11 | - https://github.com/mdn/content/pull/38977 12 | - waiting for expert review 13 | - Aaron will find someone and/or review it himself 14 | 15 | ## Future Topics for OWD 16 | 17 | - Which other attacks are worth covering on MDN? 18 | - Supply chain? 19 | - MITM? 20 | - XSRF? 21 | - Is one of these worth doing more than others? 22 | - Which of these are actionable? 23 | - Focus on the mitigations for the potential attacks 24 | - Which of the suggestions we want to give are easy to implement? 25 | - Something that developers should do but is not as widely spread in the ecosystem as we want to? 26 | - For example, MITM 27 | - It's "solved" but maybe important to explain to developers why? 28 | - To stress the best practices that we already have out there 29 | - What about supply chain? 30 | - Are all the solutions more operational? (i.e. have a policy for adding 3p dependencies, use dependabot?) 31 | - TODO: Brainstorm with Dan, what are the technical controls that are "easy" that we can provide/suggest to the community? 32 | - What about XSRF? 33 | - Are we coming from the angle of SWAG or MDN? 34 | - Unless devs are being intentionally careless and overriding the parts that are "solved" by most modern frameworks, it's hard to introduce? 35 | - But still a problem because there's tons of legacy code from before we had "solutions" that might be out-of-scope for new web devs where we want to give SWAG-focused advice? 36 | 37 | ## Quick advertising updates 38 | 39 | - Quick shout-out to SWAG in the slides for Aaron's BSides Seattle XSS talk 40 | - Would the W3C SWAG GitHub be an appropriate place for static PDF serving of slides to talks like these (so that we can link from our docs, etc) 41 | - Anything SWAG-esque to include in the Angular v20 promotion materials for Auto-CSP? 42 | - Such as what? Maybe guidelines? Angles for how to sell features like these? 43 | - Can mention that the MDN documentation on CSP is now aligned with these approaches! 44 | - Are we meeting in-person at TPAC this year? 45 | - OWD probably will! 46 | - [Docs CG](https://www.w3.org/groups/cg/docs-cg/) also started! 47 | -------------------------------------------------------------------------------- /meetings/2025-10-06-minutes.md: -------------------------------------------------------------------------------- 1 | # SWAG Minutes - Mon 6 October 2025 2 | 3 | Present: Dan, Aaron, Florian, Will 4 | 5 | ## Survey 6 | 7 | - Dan to look into the form 8 | - Dan: Need to update the text on the last page to say to join the SWAG CG 9 | - Dan: Should be ready to launch afterwards 10 | 11 | ## Supply chain attacks article 12 | 13 | - Dan: reached out to OpenSSF, unfortunately nobody commented so far 14 | - https://github.com/mdn/content/pull/41034 15 | - Will: need to address some comments from Florian but we can merge afterwards 16 | - Dan to leave a review 17 | 18 | ## Prototype Pollution PR 19 | 20 | Florian : hope this will be ready by next week's call. 21 | 22 | ## Authentication 23 | 24 | - Plan: https://docs.google.com/document/d/1miZbXVjs070J2HH0rsDxqPnUaqNtPP51Uo8d4FU6PTk/edit?tab=t.0 25 | - New own sub tree on MDN 26 | - Dan: Do you want to talk about legcy auth? Like when web developers come across HTTP auth etc. These are still used in the wild and maybe we should say "don't use them!" 27 | - Will: That's worth talking about 28 | - Dan: Also something on the usage of SMS 2FA and how it's not great 29 | - Dan: Could be that MFA is its own topic 30 | - Will: Not sure where to put it yet, information architecture problem 31 | - Dan: *ranty* Passkeys aren't always a replacement for passwords, sometimes there are still passwords and passkeys used both as ways for authentication 32 | - Will: Passkeys are still relatively new. Same for OTP etc. Its hard to know when to recommend which. 33 | - Dan: Another risk is portability of passkeys. 34 | - Will: Not sure what the story is here for the docs 35 | - Will: Passwords are good for portability and passkeys aren't 36 | - Dan: Understanding how the form interacts with the password manager is super important. 37 | - Will: There is a great article by Hidde about this: https://hidde.blog/making-password-managers-play-ball-with-your-login-form/ 38 | - Florian: How can we involve the new WICA CG? 39 | - Dan: We can loop them in our PRs 40 | - Dan: Also they might be quite focused on the promotion of passkeys 41 | - Will: Wonder if we should give them context prior to sending them PRs, like sending them this outline. 42 | - Dan: *reaches out to Hidde* 43 | - Florian: reach out to major identiy proviers such as MS Identity, Google Identity, Octa? 44 | 45 | ## Other topics 46 | 47 | - *discussion of quality of OWASP cheat sheets* 48 | - SWAG Breakout at TPAC? 49 | - https://github.com/w3c/tpac2025-breakouts 50 | - We should attend https://github.com/w3c/tpac2025-breakouts/issues/3 51 | -------------------------------------------------------------------------------- /meetings/2024-08-12-minutes.md: -------------------------------------------------------------------------------- 1 | # SWAG CG Call - 12 August 2024 2 | 3 | Present: Dan, Simone, Aaron, Jan 4 | 5 | ## Agenda 6 | 7 | ### Call Planning 8 | 9 | Dan: propose to cancel next week's call... Restart on the **26th of August**. 10 | 11 | ### To Score or not to Score? 12 | 13 | Dan: just wanted to talk about possibility of using scorecard along side of package manager (NPM) as a way to help developers gaugge security characteristics of packages: 14 | 15 | Jan: some people come with the idea that scorecard can do anything but I don't think it holds value for consumers of a package. It only tells you about current status of a project... jQuery for example... so project maintainers, repo stuff... if I pick the package from back then then the scorecard value may change... doesn't reflect the package, nor the release or anything... I say "yes" care about it when looking at packages - choose the package that is more maintained - which is one of the characterstics measured by scorecard... we should find out which are the criteria we care about and what they are weighted... measurement should be done in a way that isn't fakable... 16 | 17 | Simone: Scorecard can be a proxy for something... 18 | 19 | Aaron: At least for the information that is derived from the code in the repo, is something like this a possible solution to the "faking" solution? 20 | 21 | Aaron: [from chat] As a technical example, we are looking for a forum for getting visibility onto the outputs of this particular scanner: 22 | 23 | Dan: this is a work item for us: what are these criteria? 24 | 25 | Jan: scorecard score is more about safety than security... it does say build was / wasn't tampered with (based on build pipeline analysis) and tells you the source code probably was the one that led to the output... so I could do my own research on the source code... helps to build a chain of trust. 26 | 27 | 28 | 29 | 30 | ### W3C News 31 | 32 | Simone: review is open for the security Interest group... In general feedback has been positive... to launch in mid-September. 33 | 34 | 35 | 36 | Also the paper on identity and the web, focused on security and privacy... 37 | 38 | https://github.com/w3c/identity-web-impact 39 | 40 | ---- 41 | 42 | Call to action: add more issues to with everything the CG could/should work on 43 | -------------------------------------------------------------------------------- /meetings/2025-05-04-minutes.md: -------------------------------------------------------------------------------- 1 | # SWAG CG Minutes - 5 May 2025 2 | 3 | Present: Martina, Simone, Dan, William 4 | 5 | ## CRA 6 | 7 | https://github.com/w3c-cg/swag/issues/23 8 | 9 | Dan: We need to come up with some guidance for web developers about the relaveance of the CRA... 10 | 11 | Simone: if we have a standard and the standard is used to create open source software - in theory we should fix standard if it allows for vulnerabilities.... 12 | 13 | Dan: do we need a new document? 14 | 15 | Simone: maybe 2- something that extracts from the law and maybe a toolkit for open source developers... if I'm an open source developer... guidance or documents... e.g. publishing a policy on your website... or knowing what to do if you receive a security vulnerability report. 16 | 17 | Martina: "am I effected by the CRA" would be very useful... 18 | 19 | ACTION: Dan to start a stub document... 20 | 21 | ## New Friends 22 | 23 | Martina: I'm a web developer for 20+ years .. last 6-7 years I'm working more on security... working for an identity provider. Want to give more back to the community... would like to help with documentation... Have been reviewing... 24 | 25 | ... documentation is lacking on trusted types and CSP ... Currently writing a book... 26 | 27 | ## fetch metadata request headers? 28 | 29 | https://github.com/w3c-cg/swag/issues/13 30 | 31 | Will: I have a PR in review in MDN and one of the topics is about this... happy to have a go at this guideline. The doc I have is about attacks and this is presented as one defence. 32 | 33 | ACTION: Will to have a go on this. 34 | 35 | ## Relationship with Package Managers 36 | 37 | e.g. https://github.com/w3c-cg/swag/issues/11 38 | 39 | Aaron: this group... should focus on the developer experience... it's hard to get the pipeline working... 40 | 41 | Dan: there is an OpenSSF document about this right now ... can try to find it. 42 | 43 | Aaron: "prefer to use packages that have attestation and if you're a publisher try to use these attestations" 44 | 45 | Dan: SLSA may not be available to individual developers... 46 | 47 | Aaron: Maybe we should be advocating for better DX around these tools... 48 | 49 | ACTION: Aaron to start a PR on this.... 50 | 51 | ## Obsolete Browsers https://github.com/w3c-cg/swag/issues/20 52 | 53 | Aaron: we do have it easier on the industry side "for best experience using this version of the browser" but the messaging is more delicate when coming from W3C... 54 | 55 | Dan: relationship to web baseline here - mapping it to baseline features rather than browsing versions... 56 | 57 | ... discussion of 58 | 59 | Will: baseline is about features... whereas this is about vulnerabilities ... vulnerabilities won't show up in baseline... 60 | 61 | https://www.w3.org/2001/tag/doc/evergreen-web/ 62 | -------------------------------------------------------------------------------- /meetings/2025-04-07-minutes.md: -------------------------------------------------------------------------------- 1 | # SWAG CG Minutes - Mon 7 April 2025 2 | 3 | Present: Dan, Aaron, Will 4 | 5 | ## [MDN guide to XS-leaks](https://github.com/mdn/content/pull/38977) 6 | 7 | Dan: *has left some comments* 8 | 9 | Need more on why these attacks are a problem and what the risks are. 10 | 11 | Will: what these attacks to... I can find out if you're logged into a site, but can't get access to the content of the iFrame. 12 | 13 | Dan: ... actual risks that follow from that ... 14 | 15 | Will: privacy type things .. people that have accounts on sites that they wouldn't want other people to know about... browser history, search history. It's a privacy risk that could turn into a physical risk.. like extortion. But not content. 16 | 17 | Dan: ... can cause physical harm to people as well... 18 | 19 | Aaron: what is the boundary between privacy & security. If you're thinking about injection attacks. What is a goal - stealing information. Another example: if gmail gets hacked by a state level actor, used by dissidents... they might die. 20 | 21 | Will: a privacy violation is - the mere fact of you knowing it is a violation. If you just know my credit card # then that's a privacy attack.. if you can use it to take my money ... then it's a security attack. 22 | 23 | Dan: might want to root in the privacy principles https://www.w3.org/TR/privacy-principles/ if you're talking about the privacy / security bondary. 24 | 25 | Aaron: we're called "secure" web apps wg but we shouldn't shy away from privacy related advice. 26 | 27 | Dan: totally agree with that. 28 | 29 | Will: would prefer to focus on specifics... 30 | 31 | Dan: agree. 32 | 33 | Dan: so what that comes out of this can be put in our guidelines? 34 | 35 | Will: we could focus on the defences... we look at the defences listed here... e.g. frame protections... fetch metadata, cross-origin opener policy (COOP)... we should file an issue... Another thing that comes out is repition... frame protection... for example... 36 | 37 | ## Logistics 38 | 39 | Dan: My talk to OpenSSF day NA (June 2025) is accepted. Also I'll be out next week. 40 | 41 | ## Survey 42 | 43 | Will: It would be good to have a more detailed survey of web developers... whether web developers in general take measures against cross site links, csrf, etc... it would be interesting to find that out. Do they protect themselves, do they think they're vulnerable, do they think they understand them, where do they get their information from, what frameworks do they use, [what tools are they usuing]etc...? 44 | 45 | Dan: yes sounds good... Can we start an issue and start documenting it there? 46 | 47 | Will: will start in a google doc... and we can work on it in there. Need to talk to someone about survey design... 48 | 49 | *we agree to pursue a survey... Will to start a google doc to start the ball rolling.* 50 | -------------------------------------------------------------------------------- /meetings/2024-09-16-minutes.md: -------------------------------------------------------------------------------- 1 | # SWAG Minutes - Mon 16 September 2024 2 | 3 | Present: will, dan, okiki, randall, thomas, aaron 4 | 5 | ## Open Issues 6 | 7 | * [Work item: come up with a set of security criteria for packages](https://github.com/w3c-cg/swag/issues/1) 8 | 9 | * [Security Features List](https://github.com/w3c-cg/swag/issues/2) 10 | 11 | Dan: please leave comments on the issue... 12 | 13 | Will: One thing I'm thinking about doing on MDN is collecting things related to authentication under "Authentication"... 14 | 15 | Dan: should we focus on "baseline" issues here? https://developer.mozilla.org/en-US/blog/baseline-unified-view-stable-web-features/ 16 | 17 | * [How can we help CSP gain more adoption with Web Developers](https://github.com/w3c-cg/swag/issues/3) 18 | 19 | Will: half way through re-writing the CSP guide... and will send for feedback when that happens... 20 | 21 | * [Introduce jsr.io to SWAG discussions](https://github.com/w3c-cg/swa/issues/4) 22 | 23 | Okiki: I reached out to - Deno team - they are trying to split apart - so JSR can stand on its own... JSR is supposed to be a superset of what NPM currently is ... with goal of having support for multiple run-times... gives points or deducts points for various aspects... e.g. specifying runtimes... as a developer looking for a package, you get to see from the score how high quality the package is... If we could include security as part of the JSR score it would make ti super easy for developers.. I think JSR team could allow us to test this out on a small scale. 24 | 25 | 26 | ## TPAC session 27 | 28 | Will: added a session here: https://github.com/w3c/tpac2024-breakouts/issues/96 29 | 30 | Dan: we can talk through the feedback we received on the next SWAG call. 31 | 32 | ## Privacy Principles 33 | 34 | Dan: we're putting https://www.w3.org/TR/privacy-principles/ forward for w3c Statement. Many of these principles are applicable to web developers. Some are also overlapping with Security. 35 | 36 | ## Producing a Report 37 | 38 | Dan: i think we should build somnehting akin to the https://best.openssf.org/Concise-Guide-for-Developing-More-Secure-Software concise guide as an output for our group 39 | 40 | Aaron: timeline? 41 | 42 | Dan: end of the year? 43 | 44 | Will: how would this relate ... idea would be "101" on MDN... 45 | 46 | Dan: I think it could be the basis for both... 47 | 48 | Will: might have relations to MDN observeratory... Mozilla relaunched the observeratory .. that service sends users to find more info if it finds an issue... Sort of the same thing. 49 | 50 | Dan: will make sure it gets published in as permissive a license as possible. 51 | 52 | Will: we should have items that are actionable... For example, item 24 in OpemSSF list is "continuously approve" - so everything we list should be actionable. 53 | 54 | Dan: Yes - we should have "actionable"... Also listing process improvements separately from actionable items... 55 | 56 | Dan: I will create a stub document... 57 | 58 | ## Cancel next week's call due to TPAC 59 | 60 | 61 | 62 | -------------------------------------------------------------------------------- /meetings/2024-10-28-minutes.md: -------------------------------------------------------------------------------- 1 | # SWAG CG Minutes - Mon 28 October 2024 2 | 3 | Present: Dan, Will, Aaron 4 | 5 | ## Security group for web-features 6 | 7 | Dan: will be presenting at dev con romania next week partly on security. 8 | 9 | Will: working on listing security features and also short-description (https://github.com/web-platform-dx/web-features/blob/main/docs/guidelines.md#descriptions) for CSP 10 | 11 | - https://github.com/web-platform-dx/web-features/pull/2061 12 | - related to https://github.com/w3c-cg/swag/issues/2 13 | 14 | Will: I'm looking at the list they have to see what of what they have is a "security feature" - if others are interested in commenting that could be helpful. 15 | 16 | ## Security and privacy principles 17 | 18 | Dan: looking at https://www.w3.org/TR/privacy-principles/ I thought it might be useful to think about which security features (from that list) could be useful to implement each privacy principle that is aimed at "websites" - that is, applicable to web developers... Will file an issue. 19 | 20 | Will: related : whether you need to employ a particular protection on your site is related to what you're doing - so if you're dealing with user data then you need to worry more about XSS. 21 | 22 | Dan: [sensitive info](https://www.w3.org/TR/privacy-principles/#hl-sensitive-information) definition in privacy principles might be useful. 23 | 24 | Will: worth mentioning things that are not that obvious... 25 | 26 | ## CSP for Angular (and other frameworks) 27 | 28 | Will: want to add into CSP docs on MDN - the idea of tooling support for writing CSP. Should file an issue for tool support for CSP... whether we shoild call out particular tools or call out the idea of it... 29 | 30 | Dan: we should avoid blessing specific tools but talking .. Start from principle and then point to specific examples in specific tools - as long as there are multiple tools to point to. something something multiple implementations. 31 | 32 | Will: also there are things that tools can't do - which is useful to call out. 33 | 34 | Will: I will follow up by filing an MDN issue to talk about auto CSP... Either in general terms or refering specific to angular, or if we can find multiple instances doing that... 35 | 36 | Aaron: not much info in terms of documentation (yet, since the deadline is only for code and not documentation) but to give context [on Angular](https://github.com/angular/angular-cli/pull/28663) - the tl;dr is that auto CSP is not widely used in tooling landscape yet. We're going to await feedback between releases 19 and 20. Right now it's opt in. We'd like to move it to opt out. 37 | 38 | Dan: any blog post about the feature? 39 | 40 | Aaron: yes on the google bughunters blog... will also get some of it to the angular blog... 41 | 42 | Dan: we could get W3C to help amplify that... 43 | 44 | Dan: also channel this back through this group and the W3C, so we can talk about it as well. 45 | 46 | ## a more formal scheduling process? 47 | 48 | Aaron: I'd like to share a talk with this ... 49 | 50 | Dan: let's schedule for monday the 11th of November... 51 | 52 | -------------------------------------------------------------------------------- /meetings/2025-08-04-minutes.md: -------------------------------------------------------------------------------- 1 | # SWAG Minutes - Mon 4 August 2025 2 | 3 | Present: Will, Giovanni, Aaron, Dan 4 | 5 | ## Survey 6 | 7 | Aaron: I talked to Kadir... 8 | 9 | Will: *presents draft survey as put into Google Forms* ... last question is "do you want to participate in an inerview"... 10 | 11 | ... get a range of responses... different parts of the industry have different understandings... 12 | 13 | ... I made up some "demographics" questions ... This feels like a user research kind of thing. We have an assumption that there are different specialities that have different understandings of web security... We don't just want security specialists ... A lot of these are pretty general... Something about what sorts of role you do... generic job descriptions... also do you delegate or are responsible. Super open to feedback. 14 | 15 | ... then the top level questions... 16 | 17 | ... simplified the survey to the top level questions ... and then the detail is what we can ask in the interview. 18 | 19 | Aaron: if it is helpful, I can ask the angular devrel contacts ... on previous experience of the role / profile data... insights ... on other leading questions... 20 | 21 | ... I also chatted with Kadir... I asked for more clarification... their hesitation is that the interviews are supposed to refine the multiple choice options... the verified way was to to ask more targeted interviews and then use the survey to verify... 22 | 23 | ... but how confident are we with the multiple choice options we have for many of these? 24 | 25 | ... I think we've done a pretty good job at guessing ... just from our intuition. I'm personally having some confidence. 26 | 27 | ... My concern is that if we schedule a bunch of indepth interviews it might end up stretching the timeline... Personally I think doing this with google forms means this is an OK first pass... and we cna defend it as a pre-screener to determine good individuals to do an interview with... Then we could do something through MDN survey based on that info. 28 | 29 | Dan: I agree - I'd like to launch the survey by next week after refining the demographics info... 30 | 31 | Aaron: yes - and we should be clear that we want to do this to refine the screening process for our interviews... Depending on what we get back we do a more extensive survey .. / MDN survey 32 | 33 | Giovanni: would it be useful to add ... "can you share a contacts to pass the survey to"... Can you suggest others to send this form to (optional)... Also - related to how we want to analyze the results... manually or automated? 34 | 35 | Will: I was going to worry about that when we have results... Manually unless we have a lot. 36 | 37 | Will: is your proposal to make this survey the full thing - not just the first questions? 38 | 39 | Aaron: I wonder how many screens people are willing to sit through... We could ask people to answer optional questions.... 40 | 41 | *debate ensues* 42 | 43 | *we agree to add "do you have more detail you'd like to share" for each line-item but leave out the detailed pick-lists* 44 | 45 | ## Defcon 46 | 47 | Aaron: I'm going to be at Defcon - doing a workshop on safer coding while building web applications... I was going to ask ... is there a plug for this group or for answering the survey... 48 | -------------------------------------------------------------------------------- /meetings/2024-08-26-minutes.md: -------------------------------------------------------------------------------- 1 | # SWAG Minutes - Mon 26 August 2024 2 | 3 | Present: Dan, Simone, Will, Florian 4 | 5 | ## Agenda 6 | 7 | - Security criteria for software packages? 8 | - Status of OWD (Will's) document ...? 9 | - TPAC 10 | 11 | ## Notes 12 | 13 | - Strawman by Dan: https://github.com/w3c-cg/swag/issues/1 14 | - Not all criteria are programatically retrievable 15 | - Could feed into a list of criteria for web developers who are selecting packages 16 | 17 | Will: I spoke to Aaron and Arthur from Google last week - Some are going to be at TPAC - maybe we could have an in-person meeting. 18 | 19 | Dan: Breakout proposal maybe? 20 | 21 | Will to file a TPAC breakout session proposal. Dan to add to it 22 | 23 | Will: been writing docs about pasword based auth... most of the material comes from OWASP... but I do think there is value in having something different that is organized differently / more pragmatic... not "all or nothing" - but "these are things you have to do and these are nice-to-have"... Deep linking ... e.g. principles for password storage ... can be a good approach. 24 | 25 | Simone: OWASP .. for now they are referring to Application Security Verification Standard (ASVS)... but written not from developer's perspective... so not so easy to access... this is one issue we can solve. 26 | 27 | Will: Looking at OWASP docs with a modern web developer hat on - a lot is not relevant - e.g. how to secure applications written in languages that aren't used widely on the web any more... I'm writing docs for the 95% of people... 28 | 29 | Simone: in WebAppSec ... we have CSP ... OWSAP Sways test test for CSP header but difficult for developer to understand how to write a good CSP header... 30 | 31 | Dan: need to think about cross-browser compat, e.g. when talking about trusted types... 32 | 33 | Florian: we can list them and evaluate them across [WebDX](https://web-platform-dx.github.io/web-features-explorer/groups/) baseline... 34 | 35 | Dan: can we come up with a list of features relevant to security which can then be evaluated against the WebDX feature list? 36 | 37 | Dan: creates issue https://github.com/w3c-cg/swag/issues/2 38 | 39 | Florian: another thing from Google call - they are working with internal teams to help them adopt e.g. Trusted types - I think these stories might be interesting. "how to adopt CSP into an existing project"... 40 | 41 | Dan: Case studies... 42 | 43 | Florian: yes - and if there are such case studies and they can help us write good docs... projects that are in this journey e.g. from password-auth to passkeys... 44 | 45 | Will: I like "what is the reality"... In MDN it talks about theory ... 46 | 47 | Florian: also has to co with how good support is ... 48 | 49 | Simone: most relevant thing from WebAppSec is to solve the adoption of CSP. 50 | 51 | Florian: so CSP is widely deployed so why isn't it widely adopted... 52 | 53 | Simone: for CSP there was a study in 2020 - https://publications.cispa.saarland/2986/1/roth2020csp.pdf 54 | 55 | Dan: creates issue https://github.com/w3c-cg/swag/issues/3 56 | 57 | Simone: we maybe need to ask developers.... one of the things from the workshop - one of the best things was understanding the results of the survey... Maybe we need to a a separate survey on if developers are using CSP and if not why they are not using it... 58 | 59 | -------------------------------------------------------------------------------- /meetings/2025-02-24-minutes.md: -------------------------------------------------------------------------------- 1 | CSRF guide# SWAG CG Minutes Doc - Mon 24 February 2025 2 | 3 | Present: Dan, Simone, Lola, Will, AAron 4 | 5 | ## [CSRF guide review](https://pr38151.content.dev.mdn.mozit.cloud/en-US/docs/Web/Security/Attacks/CSRF#defense_summary_checklist) 6 | 7 | Will: I wrote a page on CSRF for MDN... which had an editorial review and approval... But hasn't had a technical review from a security expert... 8 | 9 | https://github.com/mdn/content/pull/38151 10 | 11 | ... wanted to add a guideline about CSRF ... which motivated this .. that's the next thing. 12 | 13 | *Dan to send to OpenSSF folks for feedback* 14 | 15 | *Will to draft a guideline about CSRF*- 16 | 17 | Aaron: not that many technologies that deal with server-side HTTP headers... on NPM... 18 | 19 | ## [Fetch Metadata Request headers](https://github.com/w3c-cg/swag/issues/13) 20 | 21 | - has multiple browser implementations but is not a standard - can we try to standardise it? Simone: yes. 22 | 23 | ## Web App Sec notes 24 | 25 | Permissions API update is incoming - will be moving to CR 26 | 27 | https://www.linkedin.com/pulse/from-operation-aurora-apt29-web-browsers-killchain-simone-onofri-m063f/ 28 | 29 | Subresource integrity - for dynamic content - also coming soon 30 | 31 | ## Practical/accessible guide to threat modelling 32 | 33 | (cf https://owasp.org/www-community/Threat_Modeling_Process which to me is not very accessible) 34 | 35 | Simone: we are looking for editors... in SING... still thinking ... General idea is to use the framework of "trust...?" Challenge is - we see all the threat modeling framework guidelines are for .. systems .. not for specific tiny browser APIs... 36 | 37 | Will: thinking about a guide on MDN for threat modeling for Web Applications.. the OWASP doc .. is not accessible. Reads like "aimed at security professionals" - if you're a web developer looking for guidance... we need something more practical. 38 | * "if you're incorporating input into your pages, you need to think about XSS" 39 | * "if you have a form that chanegs state on the server then you need to care about CSRF" 40 | * "If you're using third party libraries then you need to think about SRI and supply chain attacks". 41 | 42 | Simone: agree .. we could try to get an example which could cover 80% of the needs of the developer... Think about your application, think about threats... In theory, the approach of risk management. ISO 27001... Improbable that a web developer can do this .. so we need to lead by examples. 43 | 44 | *need tracking issue* 45 | 46 | ## Planned "attacks" docs for MDN: 47 | 48 | Will: working my way through docs on MDN... going to have one on CSRF soon... going to work through these things as we have time... 49 | 50 | Cross-site scripting (done) 51 | Clickjacking (done) 52 | CSRF (in review) 53 | 54 | Cross-site leaks (CORP, COOP, COEP) 55 | Supply-chain attacks 56 | Man in the middle 57 | SSRF 58 | ...more? 59 | 60 | Lola: what resources are you using to inform what you write about this? 61 | 62 | Will: OWASP a lot... a super good resource... foundation ... and I can build more accessible guides. For cross-site leaks, web.dev ... a lot of that is kind of "bloggy" - not reference docs.. I found portswigger has super good documentation... lots of good examples.. That kind of thing. Also people in this group! 63 | 64 | ## Libraries 65 | 66 | Aaron: Will be working on more material similar to what's there... 67 | -------------------------------------------------------------------------------- /meetings/2025-09-08-minutes.md: -------------------------------------------------------------------------------- 1 | # SWAG Minutes - Mon 8 September 2025 2 | 3 | Present: Florian Scholz, Aaron Shim, Will Bamberg 4 | 5 | ## Survey 6 | 7 | Will: Checked with Ruth for legal on collecting emails, still waiting on response for that. Can also host only banner and host the form ourselves -- so nothing is on MDN. If we want to do interviews, we (W3C?) need to still collect emails. 8 | 9 | Still need test subjects. 10 | 11 | Florian: Spoke to Ruth, there is now devrel on Firefox, they wanted to do a survey on just fetch and ramped up entirely on *social media*. They will let us know how it went. 12 | 13 | Will: Is this a public survey that we can see? Interesting to see if they are collecting profile data for responders? 14 | 15 | Florian: State of HTML survey just closed or about to close, 6k respondents, fewer than before, does have some demographics that we can see. Diversity numbers are hard. Can we do some outreach on social media? What accounts? OWD docs? Soverign Tech Agency? Some MDN accounts? How do we get responses different from our usual industry players accounts? 16 | 17 | Aaron: Are there any other things we need to do right now to move this survey format along? 18 | 19 | Florian: Can be a test subject. 20 | 21 | Will: Florian might be too friendly but we can try this week. 22 | 23 | Florian: Or someone else at OWD 24 | 25 | Aaron: Maybe ask Angular DevRel whether there are devs that they ask questions / surveys / interviews. 26 | 27 | Will: Still at the point where we are refining the survey questions rather than finding subjects. This is still hard because we aren't quite sure of the process. 28 | 29 | Florian: This is because we are still learning the process as we are going along-- other surveys in the space are also still struggling to get responses. We also don't know what the process for the interviews are. 30 | 31 | Aaron: Survey or interview? 32 | 33 | Will: Still not 100% set on which format-- whole survey, whole interview, or a short survey screener + followup interview. Maybe leaning towards a whole interview? 34 | 35 | Florian: Survey screener helps set the tone for the survey and helps find cool people-- but could also bias them a bit, so keep that in mind 36 | 37 | Will: Maybe demographics at least plus some base questions should be a part of the short survey for the screener. So maybe the test subject should do survey+interview? Looks like we are leaning towards hybrid option. 38 | 39 | ### TODO 40 | 41 | - [ ] (aaron) Definitely ask Simone about emails 42 | - [ ] (florian) Reach out to FF devrel for survey results / progress 43 | - [ ] Find and see not only content and/or process of Firefox quick survey? (For instance, are they looking for particular profile of responders?) 44 | - [ ] (florian) Check State of HTML survey results at EOW 45 | - [ ] Get a sense for demographic questions / data 46 | - [ ] Check security-facing questions 47 | 48 | ## Supply Chain Attacks 49 | 50 | Will: Drafted a document, here's a [PR](https://github.com/mdn/content/pull/41034) -- happy to get expert reviews as well! 51 | 52 | ## Credentials API 53 | 54 | Florian: Looking into this and seeing what documentation to expand -- physical credentials looks to be interesting 55 | 56 | Will: Is this a standard? Shipping but not standard... Still [open review](https://github.com/w3ctag/design-reviews/issues/1119) for TAG, maybe a little early to ship in multiple browsers? 57 | 58 | Florian: To discuss with Dan -------------------------------------------------------------------------------- /meetings/2025-07-28-minutes.md: -------------------------------------------------------------------------------- 1 | # SWAG Minutes - Mon 28 July 2025 2 | 3 | Present: Dan, Will, Giovanni, Simone, Florian, Aaron 4 | 5 | ## Survey 6 | 7 | https://docs.google.com/document/d/1K2ofj5JgCDgIg5-xZTFMwYXms7KXoiid-e0QucUeGyc/edit?pli=1&tab=t.0#heading=h.qc58da4eu3mq 8 | 9 | Dan: [recaps WebDX calls and feedback particularly from Kadir] 10 | 11 | Aaron: would the info coming out of web almanac be easy to query? 12 | 13 | Will: not sure .. have read it ... what's in it and what it can tell us . but haven't looked at the data... 14 | 15 | Will: ... running this as interviews is a good idea. From my PoV is that we're looking for expertise & advice on user research... We know what we want to ask but we don't know how to find it out. I'm open to professional advice... If Kadir has that advice... great. How many subjects do we think we would need? You don't need to talk to that many people... If you select the right people you don't need to do it a lot... It's a technical user research question. Given we've taken some time on this anyway, it's better to make it useful. What we want is expertise. 16 | 17 | Florian: You don't need that many people - 5 or so is what Kadir said in WebDX call... Another thing... MDN short survey are intended to be 1 minute or 2.... But this is longer form. What they are also running right now is the "state of xx" survey... E.g HTML... which has chapter on components. I thought of "state of security". that would allow for a more complex survey. I don't know how much it would cost to work with them to do this ... or if there is a project to "run your own state of x" survey... Seems like for a quantative survey... feels more like a state of thing. 18 | 19 | Will: that's promising... 20 | 21 | Florian: we could run a long-form survey with another vehicle... but by using the MDN banner,, you get the audience we are after... we want developers. With the state of X surveys it's also the same target. 22 | 23 | Dan: State of security sounds big an might be a recipe for not doing anythign soon. Could we run this survery on a freem platform, and do 5 interviews, and pursue State of as a longer-term objective? 24 | 25 | for current survey Do we focus on dev interviews / or do the survey as is or both? 26 | 27 | Aaron: I'm a big fan of running multiple survey like things... I do think we should do 28 | 29 | Dan: I suggest running the survey as is .. using e.g. google forms - and then doing some inetrviews but we need to find the people to interview. 30 | 31 | Will: we need to figure out what kind of people they are when we select them ... we could have a final question saying "are you willing be contacted for an inperson discussion..." 32 | 33 | Florian, use https://gamedevjs.com/survey/2024/ as inspiration? 34 | 35 | Florian: it might help if we could articulate who wew want to talk to. e.g. "average developer at an agegy, someone at a large corporation who's authoring frameworks, etc..." 36 | 37 | Aaron: was there a question in the survey that asks this? 38 | 39 | Will: not currenty but there should be. 40 | 41 | Dan: we should still get feedback for Kadir/WebDX. If someone can contact him this week that woud be great, otherwise Dan will next week. 42 | 43 | Aaron: What do we want to ask Kadir? It's in the Webdx call minutes from last week: https://docs.google.com/document/d/1ree75ImLZjf60lTZ3BhCaLHygxgywr7SBXp-q0xPs8A/edit?tab=t.bcoiyznc5p1o#heading=h.yf88sa4b99px 44 | 45 | Will will work on drafting "profile" questions this week. 46 | 47 | 48 | -------------------------------------------------------------------------------- /meetings/2024-07-08-minutes.md: -------------------------------------------------------------------------------- 1 | Present: DanA, Tobie, Maurice, dveditz, Jan, Simone 2 | Regrets: Florian 3 | 4 | New friends: Maurice from Mozilla - working on CTF (capture the flag contests) and bug bounty... working in security for Mozilla. In CTF you have a challenge like finding a bug... 5 | 6 | *discussion of CTF* 7 | 8 | e.g. cross-site scripting challenge... 9 | 10 | Dan: should we think about this as a way to help developers think about security issues? 11 | 12 | Dveditz: OWASP has an example... a server that has known flaws... 13 | 14 | Jan: https://owasp.org/www-project-juice-shop/ 15 | 16 | Dveditz: similar to MDN... teaching people... 17 | 18 | Maurice: https://portswigger.net/web-security is also great 19 | 20 | 21 | Daniel: Florian can't make it, but Will made his document (outlining potential web security docs) open for comments. Will's document: https://docs.google.com/document/d/1p1GtjmTd1uQrO2PRb_uUflAfQpEsfs7hBaopYeuoPMM/edit#heading=h.ck74bmw37a7r 22 | 23 | Dan: *sets doc to open to comments* 24 | 25 | Simone: I like the CTF approach... demonstrating ... 26 | 27 | Tobie: looking at will's doc... trying to understand - focusing on a dedicated part of MDN that would focus on security... But doesn't appear to address adding comments on security within the rest of the documentation... 28 | 29 | Dan: not clear if this document can also be the output document from the CG... or if it's just intended for MDN. 30 | 31 | Tobie: the info is there... the question is where to find it and how to speak in the language that the people who are implementing it can understand. If that's true then our focus shouldn't be on writing more docs in different places - so my feeling would be "there is a de facto home for stuff for the web - that's MDN" if there's one doc that's to be written then it should be really easy to be brought there. 32 | 33 | Dan: Agree 34 | 35 | Tobie: When we talk about Open Web Docs... at the secure the web forward, etc... my feeling is we identified 2 pieces missing. One is the "Web security 101" doc and the other one was "when you're in a doc about fetch (e.g.) what are the security concerns you need to think about in the context of that API" - should MDN have / should it build a commons around security. 36 | 37 | Dan: There is a need for that - so that security information surfaces in places where developers are looking anyway... We could play a role in helping to develop this hit list of MDN pages that requiure security sections... 38 | 39 | Tobie: specs that have security considerations... might be interesting - if you go into MDN and look at any random page, what comes up about security...? e.g. [`fetch` API](https://developer.mozilla.org/en-US/docs/Web/API/fetch) - it links to the fetch standard - there doesn't appear to be a section on security considerations there... 40 | 41 | Tobie: *about OpenJS Foundation* there is a security group but they are looking at security practices in the foundation. For the operational aspects... contributing and releasing projects... than for the quality of the code. e.g. 2fa management, roles and responsibilities, access rights... Also CDNs... 42 | 43 | *discussion of need for better security considerations in the Fetch spec* 44 | 45 | Tobie: I wrote the security [considerations section of the generic sensor API](https://www.w3.org/TR/generic-sensor/#security-and-privacy)... as a good example... 46 | 47 | Simone: i think this is something that needs to be done but I think *here* we should focus on web developers, not spec developers... but yes we should use security consideration sections as a [fodder] for MDN pages' security considerations sections... 48 | 49 | Tobie: work with bikshed and respec ... 50 | -------------------------------------------------------------------------------- /docs/regulatory_policy.md: -------------------------------------------------------------------------------- 1 | # Security Regulatory Guidance for Web Developers and Library Developers 2 | 3 | ## Purpose of this Document 4 | This document provides actionable guidance for web developers and developers of web libraries or frameworks on how to understand and comply with emerging software security regulations and policy guidance. It focuses on topics such as vulnerability handling, secure defaults, supply chain security, and secure software lifecycle practices. It specifically excludes privacy-related topics, so this is not about privacy regulation such as GDPR. 5 | 6 | Note that *this guide is not legal advice*; it’s just an overview to help you understand how regulatory and policy topics might apply to you. If you are looking for advice on your specific situation, please consult your own legal counsel or other detailed regulatory guidance documents. 7 | 8 | ## Scope and Audience 9 | 10 | This guidance is for web developers producing web sites or software for deployment on the web or as packaged apps (e.g., PWAs, Electron) as well as developers of libraries, frameworks, or tools consumed by the web development ecosystem. 11 | 12 | ## Understanding the Security Regulatory Landscape 13 | 14 | ### European Union – Cyber Resilience Act (CRA) 15 | 16 | Summary: The European CRA applies to manufacturers of "products with digital elements" (PDEs), including software that is placed on the EU market. 17 | 18 | #### Relevance to Web Developers: 19 | 20 | * The CRA is likely not directly applicable to general web sites or web apps deployed directly from a server. The CRA excludes web sites that do not support a product's digital functionality. 21 | * The CRA may apply if your web site or web app is integral to the function of a digital product - for example, if your web app is instrumental in controlling an IOT device. 22 | * The CRA may apply if your web site or web app is integrated into a packaged application. For example, if your web app is converted into an Electron (or similar) app and put on the market as a desktop application, or if the web pages are built to execute within a web view that is displayed within a native app, then it would be considered a product under the CRA. 23 | * The CRA most likely applies to your libraries, frameworks and tools that you sell or make available as part of a paid service to be used in other web sites. In this case your product is not the website which is not regualted by CRA but the software component placed on the market standalone as consumeable software product. 24 | * Open source library developers, if they expect that their libraries may be used by those developing PDEs, should clearly state how to send vulnerability reports, and prepare to receive and respond to those security vulnerability reports. An OSS project does not have to have a "[steward](https://openssf.org/blog/2025/06/02/oss-and-the-cra-am-i-a-manufacturer-or-a-steward/)" under the CRA, but OSS developers of widely-used or important programs may want to identify and establish a steward for it. 25 | * Open source library developers should have a a published security policy and should consider open our security guidelines for library and framework developers. This is because the CRA directs downstream users (particularly those classed as "manufacturers" of PDEs) to perform due dilligence on any open source component that they incorporate into their products. 26 | * The OpenSSF have produced a [Brief Guide for Open Source Software (OSS) Developers](https://best.openssf.org/CRA-Brief-Guide-for-OSS-Developers) when it comes to understanding the CRA. 27 | 28 | ### United States – CISA Secure by Design, US Executive Orders and Other Guidance 29 | 30 | tba 31 | 32 | ### UK Software Security Code of Practice 33 | 34 | tba 35 | 36 | -------------------------------------------------------------------------------- /meetings/2025-03-10-minutes.md: -------------------------------------------------------------------------------- 1 | # W3C SWAG Minutes 2 | 3 | Present: Dan, Lola, Will, Simone 4 | 5 | ## cross-site leaks 6 | 7 | Will: looking at cross-site leaks (https://xsleaks.dev/, https://cheatsheetseries.owasp.org/cheatsheets/XS_Leaks_Cheat_Sheet.html) ... How we can frame the documentation... 8 | 9 | Will: there's a wiki that seems to be sort of maintained... OWASP cheat sheet... Umbrella term for different kinds of attacks that exploit the way the web platform leaks info from one site to another site... E.g. access to a window reference to a target site ... there's a property called length which is exposed across origin ... length will tell you how many frames the target site has which can tell you whether a user is logged in or not... A lot of them are privacy-ajacent... The most basic versions of these attacks have been foiled but there are still some ways you can exploit this... some of them you need a browser to fix the problem... 10 | 11 | Dan: how can developers protect? 12 | 13 | Will: several different practices that can help against a lot of them - e.g. samesite lax. One cross-site leak - in the attacker's web site you try to load a subresource from a target web site... it can probe whether a page exists or not... if that reqeusst includes cookies you could potentially derrive the userid... Suggesting summarizing : here are some common cross-site-attacks and here are some common stratgies... Another one is fetch metadata. 14 | 15 | Lola: I agree - providing specific examples in detail is outside the remit... But could you link to other docs that have specific examples... 16 | 17 | Will: the wiki is probably the best source.. the OWASP document doesn't list all of them. 18 | 19 | Dan: slightly worried about linking off to an unmaintained wiki... 20 | 21 | Will: it has activity... and was written by sensible people... but it's a good question... 22 | 23 | Simone: for this point - taking a note. I'm going to ask OWASP. Or we could make it a joint work... 24 | 25 | Will: also questions on relationship between cross-site leaks and spectre/meltdown... unclear. Should it be in the same area or separate? Spectre/meltdown is a timing attack.. just gives you a way to make timing attacks more effective. 26 | 27 | Dan: I think it shold be in the same section... since that grounds it in what the actual risk is rather than the mechanism... 28 | 29 | Will: in the context of spectre/meltdown... with high res timers... shared array buffer. now you can use those APIs if you do cross-origin isolation... Then you get access to those APIs. But if you don't do anything is spectre/meltdown still a problem? 30 | 31 | Dan: I don't think so... 32 | 33 | Will: I think we can write something... 34 | 35 | ## Threat Model 36 | 37 | Simone: I started on the threat model... We have some people on social networks... who are thinking of this... 38 | 39 | https://docs.google.com/document/d/1Ppaz_EnhzHqPOz5UusRJvbSunh-RXPWgJ3Np_TM2EE0/edit?tab=t.0#heading=h.d3ody38gbyod 40 | 41 | ... our problem in mediating... I will meet Martin Thomson ... 42 | 43 | Dan: action on us to review and give feedback... 44 | 45 | ## Digital Credentials 46 | 47 | *discussion of digital credentials work in fed id working group* 48 | 49 | Dan: there is potentially a TAG finding coming your way... 50 | 51 | Simione: have discussed QR codes on the web... Another point, using custom schemes... In my opinion, cutsom schemes are worse... 52 | 53 | Dan: we [in TAG] discussed limits on the browser API to disable some key "dystopian" scenarios that would be damaging to society... 54 | 55 | Simone: we have discussed the idea of rate limiting... Also people should not use govt credentials for log in... 56 | 57 | Dan: +1 58 | 59 | Simone: different credentials with different privacy requirements... expose temetry to the browser to allow the browser to mediate... In my idea the browser should tel the user "you're using the driving license issued by xxx" ... a credential that is not prviacy preserving... 60 | 61 | 62 | 63 | -------------------------------------------------------------------------------- /meetings/2025-06-16-minutes.md: -------------------------------------------------------------------------------- 1 | # W3C SWAG Minutes - Mon, 16 June 2025 2 | 3 | Present: Dan, Simone, Martina, Giovanni Cerrato, Will, Aaron 4 | 5 | ## New Friends 6 | 7 | Giovanni 8 | 9 | ## The Survey 10 | 11 | https://docs.google.com/document/d/1K2ofj5JgCDgIg5-xZTFMwYXms7KXoiid-e0QucUeGyc/edit?tab=t.0#heading=h.qc58da4eu3mq 12 | 13 | Will: the idea is to understand what security features people are using and also why ... want to look at the web almanac security chapter ... tells you lots, but doesn't give motivations. We want to know how many uses about fetch metadata and how many use it... why they're not using it if they're not using ... from a technical writing pov want to see what we need to better explain... A starting point of SWAG was a survey - people said they found it hard to deal with security - but we don't know what they find hard and how they find it hard... 2 main sections to the survey - one about attacks and one about features... if we wanted to simplify we could just ask about features... does it make sense to have both? 14 | 15 | Dan: I think both is fine ... 16 | 17 | Simone: I think both ... +1 ... also ... we can explain threats, features and mitigations... 18 | 19 | Martina: we could say "do you defend about XSS" .. we could have the link from the features to the attack... 20 | 21 | Dan: could be a way to help inform the community... 22 | 23 | Will: suggesting still separate sections ... or 24 | 25 | Martina: talking about features in the context of attacks... 26 | 27 | Martina: So they come to learn "ah I didn't know I could use trusted types to protect against XSS"... 28 | 29 | Will: one challenge ... a lot of features address multiple attacks - 30 | 31 | Martina: it's true... but also informing what kind of features could be used ... 32 | 33 | Will: another thing... attacks a bit more abstract .. but features are more concrete... 34 | 35 | Dan: suggests keeping structure but back-linking from features to threats.. 36 | 37 | Dan: free text? 38 | 39 | Will: Yes I think so... 40 | 41 | *agreement to use free text as long as we have multiple choice as well* 42 | 43 | Simone: free text should be optional. Also we should add "click jacking"... 44 | 45 | Will: +1. 46 | 47 | Martina: if they look at XSS ... then later they will be asked about features... 48 | 49 | *discussion on how much we should repeat in the survey* 50 | 51 | Simone: do developers .. need new new security features? what are we missing? Some feedback from web developers can help. 52 | 53 | Aaron: going back to CSP and tursted types example... do we show / hide based on responses? 54 | 55 | Dan: Suggest we keep things flat. 56 | 57 | Aaron: +1 - also to Simone's point... suggestions for new features... a lot of folks show up in WebAppSec wg... but I want to +1 to think about this more generally... to collect developer feedback... a complementary set of information. 58 | 59 | Dan: suggest 2 weeks to put it into survey form... 60 | 61 | Will: I will also bring it up at the docs CG... 62 | 63 | ## https://docs.google.com/presentation/d/1AZsyHLiNhE2PoTbqSjpnzxcsA4DQ-rl1MetRWI8lS_E/edit?slide=id.g3682ac41ad4_0_70#slide=id.g3682ac41ad4_0_70 64 | 65 | ## Threat Modeling 66 | 67 | Simone: in the index.md there is the thread model for the web platform... the original idea was to provide this to web api developers... so they have an idea of all the threats ... it can also be used for web developers... Also I am working on digital credentials API... can be useful as a checklist... we cna provide something as a checklist... for web app developers, for web browser API developers... 68 | 69 | Simone: when groups start doing the S&P questionnaire it's a bit too late... So we can give them a brief guide. 70 | 71 | ## Regulatory 72 | 73 | https://github.com/w3c-cg/swag/pull/25 <-- seeking feedback 74 | 75 | ## Trusted Types API 76 | 77 | Will: (just a point of information) https://github.com/mdn/content/pull/37952 - Hamish is adding trusted types to the reference docs for injection sinks 78 | -------------------------------------------------------------------------------- /meetings/2025-09-15-minutes.md: -------------------------------------------------------------------------------- 1 | # SWAG Call 15 September 2025 2 | 3 | Present: Dan, Florian, Giovanni, Will, Aaron 4 | 5 | ## Survey 6 | 7 | OWD will be putting work on this ... 8 | 9 | Open issue: we are waiting ot hear back from W3C on the legalities. 10 | 11 | No update from Mozilla thus-far. They are running a survey in social media. We hope to learn from their results - on just using social channels. 12 | 13 | Dan: I think we should run with this survey... 14 | 15 | Florian: yes, and... we should dry-run the survey with test subjects... 16 | 17 | Will: the "why" questions are the most valuable... we do have some of that in the script for the why questions... if we do get people it's important... to get the "why"... 18 | 19 | Plan of record: we have the google form that has the short version of the survey - we promote that on existing social media channels, we collect responses on that basis - collect people who want to be interview subjects for that and then we conduct the interviews... 20 | 21 | Dan: As long as we a re clear in the survey that the colleciton of PII is optional and that purpose is limited to contacting people for the interview. 22 | 23 | Will to complete and Dan to work with W3C staff to get this double-checked. 24 | 25 | ## PR 29 on Policy document 26 | 27 | https://github.com/w3c-cg/swag/pull/29 28 | 29 | ## Documenting Web Security Attacks 30 | 31 | ### Supply Chain attacks 32 | 33 | https://github.com/mdn/content/pull/41034 34 | 35 | Will: we would like some review from experts. 36 | 37 | Dan: I reached out to the OpenSSF slack to get additional eyes on this. 38 | 39 | ### SSRF attacks 40 | 41 | https://github.com/mdn/content/pull/41105 42 | -> merged 43 | 44 | ### Phishing attacks 45 | 46 | https://github.com/mdn/content/pull/41115 47 | 48 | Will: Currently a draft PR - mostly want to figure out how deeply to go into web auth... How much in this guide? Right now it's pretty light on webauthn... Also: we could talk about the challenges of using webauth right now ... right now webauthn / passkeys is the only strong defense against phishing ... but what's the state of support? 49 | 50 | Dan: see also https://lucumr.pocoo.org/2025/9/2/passkeys/ 51 | 52 | Will: good article - talks about the lock-in and portability issues... We should figure out how we can talk about portability and vendor lock-in with webauthn... 53 | 54 | Will: you can never "see" a passkey. you're always reliant on mediating tools. IN terms of agency that's a problem. 55 | 56 | 57 | ### Other attacks? 58 | 59 | - (Florian) We currently have a few attacks documented. What else do we need? Do we have the most important ones done? https://developer.mozilla.org/en-US/docs/Web/Security/Attacks 60 | 61 | Florian: working on "attacks" are there other attacks we should write articles about? I also noticed that OWASP top 10 2025 will be released this fall.. not sure the top 10. May be good timing to we have the top 10 for 2025 documented. Now is the time to let us know this... 62 | 63 | *we discuss how to prioritize attacks* 64 | 65 | Aaron: protoype evolution and injection type attacks... are prevelant... We have to rely on trusted types eg. ... We also have some focus on isolation based attacks .. timing attacks. For deomonstratable impact it's definitely injection based things... 66 | 67 | Will: on OS top 10, I looked at it... one thing I think is that they used a different taxonomy... "broken access control" e.g. - it's not a single attack. We're talking about "specific thing that can go wrong and how you can fix it". Another thing I caution about is exhaustiveness.. how do we balance? 68 | 69 | Aaron: other point - on the topic of scoping down ... we have this unique intersection including the work that w3c is doing... E.g. Authorization bypass is less important to focus on than XSS type attacks.. Problems that are because of the intersection with web platform architetcure. 70 | 71 | ### updating our own guide 72 | 73 | Will: yes - the security guidelines doc is organized in terms of things you should do. However there are things like supply chain defenses and some others that could need more material. 74 | 75 | -------------------------------------------------------------------------------- /meetings/2024-10-07-minutes.md: -------------------------------------------------------------------------------- 1 | # SWAG Minutes - Mon 7 October 2024 2 | 3 | Present: Dan, Oliver Dunk, Randall, Will, Simone, Okiki, Estelle, Aaron 4 | 5 | ## Intros 6 | 7 | Oliver: Developer Relations Engineer working on Chrome Extensions as part of the Google Chrome team. Interested in general web security and also Chrome Extension security. 8 | 9 | Dan: [opens issue 5](https://github.com/w3c-cg/swag/issues/5) on extensions 10 | 11 | Will: also interested in extensions security... 12 | 13 | Simone: on extensions ... at TPAC we worked on extensions and also manifest extensions... kind of a threat we need to think about... 14 | 15 | Estelle: arguing we should have security concerns for all pages in the docs... 16 | 17 | ## Outcomes of TPAC 18 | 19 | Minutes: https://www.w3.org/2024/09/25-mdn-security-minutes.html 20 | 21 | Will: haven't cleaned up minutes yet... like estelle mentioned, the idea of having security considerations sections for non security features on MDN... Everyone thinks its a good idea... A bunch of talk about how it's possible to "find developers where they are" ... find ways to to be in their workflow... 22 | 23 | Will: I could write something up about it... like for a blog post... 24 | 25 | ## New CSP guide on MDN 26 | 27 | -> https://github.com/mdn/content/pull/36157 28 | 29 | (this is just an announcement/request for reviewers) 30 | 31 | Will: there is an open PR - I would appreciate some review comments. Got some from Aaron already - appreciated. 32 | 33 | ## Document attacks on MDN? 34 | 35 | - attacks are rather chaotically documented on MDN at present 36 | - Should we have dedicated/organized pages on attacks? Which ones? 37 | - XSS, clickjacking, Spectre/Meltdown, CSRF, MITM, ...? 38 | 39 | Will: sort of documentation for attacks but . need more... also wasn't able to get a good understanding of e.g. spectre/meltdown out of MDN. That seems like a project. 40 | 41 | ## Security Considerations for non-Security APIs in MDN 42 | 43 | Dan: we could start collecting non-security related specs which should have security considerations sections - 44 | 45 | *will to open issue* 46 | 47 | ## First Draft Security Guidelines Doc 48 | 49 | https://github.com/w3c-cg/swag/blob/main/docs/security_guidelines.md 50 | 51 | Oliver: breaking it down by "type of web application"... felt like it's jumping between types... Also jumping between things like server and front end code... 52 | 53 | Dan: may think about about types... i think we could categorize between "front end code" and server config stuff... 54 | 55 | Simone: thinking also about the awesome format that we can use for the lists https://github.com/topics/awesome 56 | 57 | ## Threat Modeling 58 | 59 | Simone: we're going to start the Threat Modeling CG .. two models for now: one for digital credentials and Tom from WICG Digital Credentials started a model for AI attacks... I'm still working with him on that... 60 | 61 | Simone: In general, we can consider different type of threats, such as the one related to human rights... 62 | 63 | Simone: We received also a request from the threat model for the web, for SING. As we have different threat types, we have also different "level" such as the levels defined here https://arxiv.org/abs/2408.03578, e.g., they have - business level or environment level threats... useful for scoping. We can think about things like credit cards... 64 | 65 | Simone: we could start creating a threats list by ourselves... 66 | 67 | Simone: for generic threat model this exists: https://www.threatmodelingmanifesto.org/ 68 | 69 | Dan: for our document we can refer to this... 70 | 71 | ## OpenSSF SOSS Community Day 72 | 73 | Dan: presents [slides given at SOSS Community day](https://docs.google.com/presentation/d/18iOsWdh_LG_gqUdSW7XfE5UOoB6_Zfi_B2XDDurPRUc/edit?usp=drive_link) 74 | 75 | ## Outputs from WebAppSec at TPAC 76 | 77 | Simone: Aaron's point - to make the web developers adopt CSP... integrtaing CSP into frameworks... this could be a collection point to knock on doors and push this point (with framework developers) 78 | 79 | Aaron: depending on the framework there will be different levels of difficulty... Wordpress will be difficult. This is a good conversation to start. 80 | 81 | Aaron: [to open issue] 82 | 83 | Will: we tried opening up a CSP using netlify instructions and it completely failed... we think the netflify instructions might be in error... 84 | 85 | Aaron: we might be able to help. 86 | 87 | 88 | 89 | -------------------------------------------------------------------------------- /meetings/2024-10-21-minutes.md: -------------------------------------------------------------------------------- 1 | # SWAG Minutes - Mon 21 October 2024 2 | 3 | Present: Dan, Will, Estelle, Aaron, Florian 4 | 5 | ## Some Calendar Issue today 6 | 7 | the meeting invite didn't get sent out for some reason - dan to chase 8 | 9 | ## Draft Guidelines Doc Update 10 | 11 | https://github.com/w3c-cg/swag/blob/main/docs/security_guidelines.md 12 | 13 | Dan: *presents* 14 | 15 | Aaron: workflow? 16 | 17 | Dan: please open issues labeled `guidelines doc` and we can go from there... 18 | 19 | Will: thing to think about: where is it going to point to? 20 | 21 | Dan: openssf resources, owasp resources, openjs resources, w3c resources, mdn resources 22 | 23 | ## Draft OWD Blog Post 24 | 25 | https://github.com/openwebdocs/owd-website/pull/132 26 | 27 | ## Feedback on "Practical security" 28 | 29 | https://docs.google.com/document/d/15EAWciPStY6zqZ5G7GljTpCX71KJZddtQwPrlq1dwu8/edit?usp=sharing 30 | 31 | - Chris Mills created this doc in response to some of my comments on the "Practical security implementation guides" on MDN. 32 | 33 | https://developer.mozilla.org/en-US/docs/Web/Security/Practical_implementation_guides 34 | 35 | Will: mozill have "mozilla observatory" - it finds problems and points to solutions - that content used to live on security.mozilla.org - that has now moved to MDN. That has some relationship to security 101 and Guidelines... I've had feedback on this - also related to CSP guide. Chris put all those comments into a doc... 36 | 37 | ## CSP guide update update 38 | 39 | github.com/mdn/content/pull/36157 40 | 41 | - close to merging, comments from Mozilla? 42 | 43 | Will: guide does not mention strict CSP at all.. should we be recommending strict CSP to the exclusion of allow-list CSP... 44 | 45 | Aaron: do we know what the concerns are? 46 | 47 | Will: strict CSP is just not mentioned in the existing docs, we don't know if this is by design or accident 48 | 49 | Aaron: owasp cheat sheet was updated last year to promote strict... 50 | 51 | Dan: *opens [issue](https://github.com/w3c-cg/swag/issues/6)* on guideline doc to reference it. 52 | 53 | Aaron: I will take another pass on Will's PR 54 | 55 | Will: someone said it might be a good practice to document attacks - that sounds sensible. We'll have docs on common security attacks on MDN. 56 | 57 | ## Isolated Contexts 58 | - see https://github.com/WICG/isolated-web-apps 59 | - recommends a "rigorous" CSP and other things 60 | 61 | Florian: in browser compat data - there are new APIs guarded behind "isolated context" - recommends **rigorous CSP**. I wonder if this group is aware of it... 62 | 63 | Dan: recommend that since these are google-only right now (and not baseline) ... 64 | 65 | Florian: yeah but these will need to be documented anyway so ... 66 | 67 | Aaron: we still want the info out there .. 68 | 69 | Florian: there might be guidelines in here about use of "scary" APIs that we could use... 70 | 71 | Will: like cross-origin-isolation.... 72 | 73 | Florian: for old APIs - we saw that 'secure context' was retroactively applied to certain APIs... so not sure of some APIs will retroactively get "isolated context." 74 | 75 | Will: "secure context" - it's widespread now so we don't think about it.. 76 | 77 | ## Adding CSP to Web Features 78 | 79 | - https://github.com/web-platform-dx/web-features/pull/1959 80 | 81 | Florian: i have a PR against Web Features on CSP... 82 | 83 | ## Baking guidelines into developer tooling... 84 | 85 | Aaron: how can we ... do this. I'm working on it with Angular. This opens up a bigger philosophical question - do we want to pursue this / publicise this - so frameworks do more secure things by default. By angular 19, the idea is that tooling will generate a hash-based CSP for you... 86 | 87 | Dan: we could use tracking issues in our repo... 88 | 89 | Aaron: would it be appropriate to say "web frameworks should do xxx" and here's an example of something that does it... 90 | 91 | Dan: I think it's appropriate to point to examples but only if there is more than one example 92 | 93 | Dan: do we need a guidelines doc for frameworks and libraries? 94 | 95 | Will: first comment - this auto CSP thing - only protects you from client-side XSS.... 96 | 97 | Aaron: yes ... 98 | 99 | *some discussion on this* 100 | 101 | Will: some guidelines on "auto CSP" would be useful - what it can do and what it can't do - and this also could reference the work in Angular and other libraries... (e.g. Netlify). I'm interested in this idea of how a particular CSP fits into a particular architecture... 102 | 103 | Dan: *will start a skeleton* 104 | -------------------------------------------------------------------------------- /meetings/2025-05-12-minutes.md: -------------------------------------------------------------------------------- 1 | # SWAG Minutes Doc - Mon 12 May 2025 2 | 3 | Present: Dan, Aaron, Simone 4 | 5 | ## Notes from discussion... 6 | 7 | ### Tools 8 | 9 | Have some conversations in OpenSSF about contributing some of the open source tools. Even if the tools aren't contributed, could we point to them or help promote them more from SWAG or from OpenSSF? 10 | 11 | ### Package Managers 12 | 13 | * What can NPM do for additional feature work - especially UX - for security mechanisms? 14 | * Dan to find more out about OpenSSF packaging work stream… 15 | 16 | ### Dev Rel 17 | 18 | * What can we be doing additionally 19 | * What channels can we use in W3C or OpenSSF to help promote our work 20 | 21 | ### Ideal survey time line 22 | 23 | Survey this summer, integrate output into documents this fall... 24 | 25 | ### General time line 26 | 27 | Try to be "wrapping up" by end of year - that is, having the documents in good condition and either moving the group to maintenance mode or closing the group and moving the ongoing maintenance to the Documentation group? (Let's discuss in the call.) 28 | 29 | Having a session in Kobe where we talk about the journey. 30 | 31 | ### Ideas for improving the pipeline for getting new people engaged in SWAG 32 | 33 | * Doing more social media out reach from W3C and OpenSSF? 34 | * Post on the google security engineering blog? 35 | * Put something on the Samsung web dev blog? 36 | 37 | 38 | ## Discussion on "end state" 39 | 40 | Dam: outlines the potential timeline (drafts by June, then bring in feedback from survey and elsewhere, then work on 2nd draft to present at Kobe...) 41 | 42 | Aaron: Working on: "the problem spaces in web security where we have good solutions " 43 | 44 | ## Discussion on current state 45 | 46 | Will: In the guidelines doc I think most of the security features are done.. but the security practices side needs to be updated and expanded. 47 | 48 | Dan: that sounds sensible. 49 | 50 | Dan: For Libraries we need feedback from library and framework developers - e.g. we could outreach to OpenJS and other places. 51 | 52 | Aaron: Agre e- question is do we need more items or do we need more info in each section... Do we see this as a superset? 53 | 54 | Dan: i agree - it's additional stuff that we didn't cover in the main document.. or we could have additional info on some of the same topics and then reference ... 55 | 56 | Will: it's always a question... how much to copy vs refer to other things... Can we give an example of a practice that library developer would follow that a web dev wouldn't care about? 57 | 58 | Aaron: e.g. an attestation in their secure build... Maybe we should make this like an "extention pack"... 59 | 60 | Aaron: when we have a library CSP .. it's trying to make your app compatible with 1000 other CSPs out there.. a slightly harder take on the problem.... 61 | 62 | Dan: Also there are other documentation ... 63 | 64 | *discussion on whetehr we recommend web developers to have a security.md file - the consensus is that it's a slightly different take since libraries / frameworks are by default open source and 3rd party developers depend on them.* 65 | 66 | *ACTION: Dan to reach out to OpenJS and OpenSSF to review our libraries guidelines and suggest addition wording* 67 | 68 | *ACTION: Aaron and Dan to focus on the libraries guidelunes.* 69 | 70 | *Will to focus on general web develper guidelines* 71 | 72 | ## Discussion of Packaging Ecosystems 73 | 74 | Aaron: support for features... how to make recommendations actionable... so for NPM how can we encourage them to make the product align with the recommendations... 75 | 76 | ## Survey 77 | 78 | Dan: How can we jumpstart? 79 | 80 | Aaron: can we take a cue from other surveys... 81 | 82 | Dan: build on the survey from the workshop... https://github.com/web-platform-dx/developer-research/blob/main/mdn-short-surveys/2023-05-15-security-dx/interpretation.md 83 | 84 | Will: what I would love to see - how many people using each feature "e.g. fetch metadata"... if they're not using it why not? On the back of the work we've done... 85 | 86 | Simone: 87 | 88 | Dan: suggests starting with a re-run of the survey we did last time - but then adding some additional questions as will suggests - specific use of security features... 89 | 90 | Will: and ask them "would you be willing to participate in an interview about this?" 91 | 92 | **ACTION: Simone to talk to Dom** 93 | 94 | **ACTION: Will to generate a list of web features to add to the survey** 95 | 96 | Dan: by next week let's see if we can get a time line for running this.... 97 | 98 | Will: also there's the web almanac ... it's good, but it won't tell you about motivation https://almanac.httparchive.org/en/2024/security 99 | -------------------------------------------------------------------------------- /meetings/2024-08-05-minutes.md: -------------------------------------------------------------------------------- 1 | # SWAG CG Minutes - 5 Aug 2024 2 | 3 | Present: Dan, Okiki, Randall, Aaron 4 | Regrets: Simone 5 | 6 | Agenda: 7 | 8 | * Intros 9 | * Randal - work at ThunderStrike and NVIDIA - was at LF 10 | * Okiki - was at LF - maintainer of Astro 11 | * Aaron - software eng at Google - adding web security to web apps at Google - looking to share info others developers.. 12 | * Will - Tech writer at Open Web Docs - trying to write docs for developers on web developers & fill in gaps for security documentation - mostly working in MDN but not dogmatic 13 | * Aaron's Talk at AppSec Village at DEFCON - looking 14 | * (Will) (if there is time) state of web security "reality check". Which security APIs in the web are "spec fiction"? What's the actual state of things for most developers? 15 | * Current state of Will's Document 16 | 17 | ## Aaron presents some slides he's planning to give on Web security 18 | 19 | [...link pending...] 20 | 21 | *XSS, etc... -- so how do you migitage against XSS using CSP? Focusing in on the different types of CSPs that can protect against XSS... Nonce-only CSP (one-time value); Hash-based CSP (hash of the script); Trusted Types (header with trusted types - blocks strings to dom APIs) - caused DOM XSS to be blocked...; DOMPurify abstracts the complexity away from you; Then focusing on **tactics** : using frameworks, enforce early, rely on the right tools, be mindful of third party dependencies. 1. Framweworks with context-aware templating and secure-by default - e.g. Angular, Lif, Next.JS, React (trusted types compat); (2) enforce early - if you have control over back-end you can add headers there... (example with ViteJS) ... but also can be done with meta tags (hash-based policy). This can mean manual work... but can be easier with tools. github.com/google/strict-csp ... ; (3) Tools - tools that help you understand your congiguration - e.g. CSP Evaluator; tools for refactoring - to try to steer dev in right direction; e.g. eslint plugin called github.com/google/safety-web. web.dev/articles/trusted-types/#fix-violations; Safevalues library - uses typescript type system to enforce provenance; (4) Dependencies - right now difficult to evaluate what's safe / not safe ... but if you do patch these libraries, please upstream the fixes. 22 | 23 | Future vision: Frameworks + Nonce / Hash-only CSP + NO DOM API Usage ("Perfect Types") can really reduce XSS attacks. 24 | 25 | Dan: dependencies - we can focus on e.g. scorecard score, etc... 26 | 27 | Will: frameworks, libraries are more volatile than web standards... a lot of tools are fashionable... so documentation can start to look out of date [when you talk about tools]... 28 | 29 | Okiki: Found that developers - dev experience more important that security - incredibly important aspect of the developer ecosystem... causes reistence... So if your CSP is not up to date it can cause breakage... how can we ensure tools are used ... 30 | 31 | Randall: Content wise good... In my exp presenting at Defcon having a narrative can be important... 32 | 33 | Aaron: *addresses above* 34 | 35 | (Will, for reference, MDN resources on XSS and SRI, nonce: 36 | - https://developer.mozilla.org/en-US/docs/Web/Security/Types_of_attacks#cross-site_scripting_xss 37 | - https://developer.mozilla.org/en-US/docs/Glossary/Cross-site_scriptinghttps://developer.mozilla.org/en-US/docs/Web/Security/Practical_implementation_guides/SRI 38 | - https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity 39 | - https://developer.mozilla.org/en-US/docs/Web/HTML/Element/script#nonce ) 40 | 41 | Okiki: is unsafe eval a good practice? 42 | 43 | Aaron: it is a bad practice but less bad when you have trusted types ... 44 | 45 | Will: on MDN... we talk about XSS.. this talks about problems that occur through to specific features (e.g. CSP, nonce, etc...)... That's what currently missing on MDN... 46 | 47 | Dan: contributing some of these into more neutral space? 48 | 49 | Aaron: yes or into projects that have maintenance budget... 50 | 51 | Okiki: a number of tools in NPM registry - that only have one developer - but ... 52 | 53 | ## state of web security "reality check". Which security APIs in the web are "spec fiction"? What's the actual state of things for most developers? 54 | 55 | Will: looking at refactoring credential management API... and got feedback that people don't use it...Would like to have more data on adoption and use of these APIs... E.g. web authentication... 56 | 57 | Dan: could we systemetize... using e.g. BCD data? 58 | 59 | Dan: maybe a survey of security related docs in MDN that are out of date or out of step with the current usage patterns? 60 | 61 | Aaron: if you're looking for qnatativie data... there are use counters (?)... Can our browser vendor friends implement use counters? 62 | 63 | Okiki: we have browser compat feature set - but we need security implications for features... "it works but you may want to check out trusted types to make it secure".. 64 | 65 | Will: agree - 66 | -------------------------------------------------------------------------------- /meetings/2024-12-09-minutes.md: -------------------------------------------------------------------------------- 1 | # SWAG CG Minutes - Mon 09 December 2024 2 | 3 | Attendees: Dan, Simone, Lola, Aaron, Will 4 | 5 | ## New Friends 6 | 7 | Lola: a technologist working in web standards - IE in the ARIA working group - and involved in the WebDX and Privacy community groups... 8 | 9 | ## Videos for two week's call 10 | 11 | Simone: we have the approvals - to post the videos - we need to plan when they go to YouTube... and we need to write a blog post. 12 | 13 | Aaron: social networking... 14 | 15 | Simone: we'll post on mastodon... bluesky... LinkedIn... 16 | 17 | Hopefully something to put out before the end of the year? Depends on how long the edits take, any text for blog posts, etc. Dan is willing to help with text if need be, maybe Aaron too. Christmas present to have a CSP video out! 18 | 19 | ## Security Principles for libraries 20 | 21 | Aaron: What distinguishes our documentation from other documentation out there? Such as OWASP Top 10 or some other security guidelines documetations? 22 | 23 | Dan: Ours should be a bit more detail. Start out with deliverables from this group-- document created by many of the parties represented at SWAG. Promote under W3C banner to be better aligned with stuff coming out of W3C like CSP. OpenSSF can help promote this documentation, maybe republish with attribution-- a "stamp of approval". Eventually adopted by Will & co in MDN, hopefully? 24 | 25 | Aaron: How is it different from OWASP? Focus on the techniques more than the threats? 26 | 27 | Dan: That and also *web* application developers. 28 | 29 | Will: Do web app developers use OWASP? How do they use it? It seems inaccessible from the end developer pov. Also sometimes outdated. When working on MDN-- have to ask "what is relevant now?!" 30 | 31 | Simone: Not a developer, but OWASP is for *security* people, not for developers. There are some parts that are for developres, but haven't heard of a single developer using it. Also Top 10 has 30 points per item, so it's more like 300 items. 32 | 33 | Dan: Let's say what we have to say, and if it ends up duplicating someone else's work, we will resolve that when we get there. Even in the draft of the end dev doc, it's a combination of things that we don't see elsewhere-- especially "how to use technologies produced at W3C" and "how to think about supply chain" and "how to take advantage of secure software development best practices". It's the combination that's the sweet spot. 34 | 35 | Aaron: We feel the most strongly about making the point that libraries should be CSP & TT compatible-- libraries should not stand in the way of end app developers who want to enforce these security features. 36 | 37 | Lola: Libraries are built on top of Web APIs-- for instance, peer.js on top of WebRTC, so shouldn't the library's security concerns be the same as the API surface's? What wasn't covered in past discussions around the security of the web APIs? 38 | 39 | Aaron: There are a lot of really insecure APIs from the past, like `.innerHTML` assignments, that features like Trusted Types tries to block. 40 | 41 | Dan: Additional security considerations from secure software developer best practices-- like 2fa for repositories and also how easy is it to inject crypto stuff into Web3 42 | 43 | Aaron: What are some actionables? Can write something around CSP & TT. 44 | 45 | Dan: Can write something around secure software development best practices. Also see what OpenJS items are applicable to us-- by next week anyway. 46 | 47 | Lola: Maybe helpful to agree on a Table of Contents before writing our sections? Lola and Will can do this-- maybe even discussing in the slack channel. 48 | 49 | Dan: We can start adding some unordered points and then we will turn it into a developer's journey. 50 | 51 | Simone: Contact from OWASP-- send them something about what we're doing about security at W3C? 52 | 53 | Dan: Invite them to the next meeting? 54 | 55 | ## OpenJS folks discussion 56 | 57 | Document in progress https://github.com/openjs-foundation/security-collab-space/blob/main/OpenJS_Security_Compliance_Guidelines/categories.mds: 58 | 59 | "Telegraphic"-- not as much description, build something that can be programatically scanned for. Primary audience is OpenJS foundation projects. 60 | 61 | Not as much distinction in the OpenJS world view between serverside and clientside JS-- node or browser. Very telegraphic. Probably a superset of the guidelines we are looking for at SWAG-- we want more text, description, and links to learn more about a particular topic. Something more readable like a document. 62 | 63 | Maybe look at the OpenJS material as source material to align with so we aren't using different terminology. 64 | 65 | Lola: Privacy guidelines? 66 | 67 | Dan: We are looking for two docs, one for end developers, and another one for developers of libraries, focusing more on the frontend but meeting the needs of library maintainers. Eventually "how do you select libraries that adhere to security best practices"? 68 | 69 | Follow-up call next week with OpenJS to talk more about the document in detail. 70 | -------------------------------------------------------------------------------- /meetings/2024-07-29-minutes.md: -------------------------------------------------------------------------------- 1 | # SWAG CG - Mon, 29 July 2024 2 | 3 | Present: Dan, Will, Aaron, Florian, Bjarki 4 | 5 | Dan: We've done intros and talked about the shape of this group. 6 | Dan: Let's focus on threat models today 7 | Dan: Documenting the threat model, it can mean a lot of things, it is a bit of a buzz word. 8 | Dan: Simple language to explain what is happening to users. If a bad actor is involved, introduce it. 9 | 10 | Bjarki introduces himself. Working on Trusted Types, web app security things 11 | 12 | Will introduces himself: Works for Open Web Docs. Recently tried to started the project to get better security docs on MDN. Not just documenting features, but also conceptual things. 13 | 14 | Dan introduces himself. 15 | 16 | Florian introduces himself: I invented compat data. Boom. 17 | 18 | Dan: Everything is minuted and public. Please let us know when you don't want something in the minutes. https://github.com/w3c-cg/swag/tree/main/meetings 19 | 20 | Dan: Audience: web developers, but also framework authors (multplication effect). 21 | 22 | Dan: Trusted Types or CORS are difficult to understand from a web developer's POV. 23 | 24 | Dan: If you don't even realize these topics are "your" problems, then how can we introduce this to web developers? 25 | 26 | Dan: Spectre or data leakage explainers don't talk about what web developers/end users need. 27 | 28 | Dan: Where do we think the threats are in common web apps? E.g. in online banking, or government websites. What are the targets? Common user stories 29 | 30 | Will: In the content content outline, I want to tie user needs and threats. 31 | 32 | Will: Walked through the cheatsheets on OWASP and other resources and then decided what is most important, and connect that with what web developers want to do usually. 33 | 34 | Will: connect security practices and things web developers want to do 35 | 36 | Will: MDN is pretty good at documenting web platform features like CSP, SRI, Trusted Types et. 37 | 38 | Will: There aren't many docs on how to do things in practise, like how to do auth. 39 | 40 | Will: Interested in getting feedback on the doc 41 | 42 | Will: Authentication: Do you want separate guides for each auth method for example? 43 | 44 | Will: Content outline: https://docs.google.com/document/d/1p1GtjmTd1uQrO2PRb_uUflAfQpEsfs7hBaopYeuoPMM/edit#heading=h.ck74bmw37a7r 45 | 46 | (discussing the outline / sections) 47 | 48 | Dan: How do you think about threats? How do you prioritize? 49 | 50 | Aaron: Different approaches, e.g. bug bounty bugs, but also systematically trying to elimnate issues. 51 | 52 | Bjarki: Try to have web developers not to think about security anymore. Eliminating risks at the framework or platform level. 53 | 54 | Bjarki: Framwork vs web developer security configurations are different. 55 | 56 | Dan: Agree, these are different crowds. We need to address both. 57 | 58 | Dan: Be aware of security when you select a framework. 59 | 60 | Will: No web developers should implement their own web auth, frameworks take care of this stuff. hard to recommend good frameworks, libraries, ... MDN typically doesn't recommend particular frameworks. 61 | 62 | Aaron: Whats the MDN policy for links to frameworks? 63 | 64 | Will: We usually don't accept links to 3rd party to libraries etc. Seeing a lot of spam. 65 | 66 | Dan: Criteria are sometimes measured by openSSF score scards. is it well maintained, does it have a code owners, CoC, etc. Could be one way to figure out what to point to. 67 | 68 | Will: 1) give developers criteria to chose, 2) give actual recommendations. 69 | 70 | Will: BCD has criteria for adding a new browser, we want something similar here 71 | 72 | Start with criteria and then present tools. 73 | 74 | Dan: Attacks section in the outline 75 | 76 | Dan: https://w3cping.github.io/privacy-threat-model/ Privacy threat model document. Some privacy threats are also security threats 77 | 78 | Will: Maybe we should have threat model as a top level section 79 | 80 | Florian: developers found understanding security threats to be challenging https://github.com/web-platform-dx/developer-research/blob/main/mdn-short-surveys/2023-05-15-security-dx/interpretation.md in the survey we ran. Even when they know what is a threat, they struggle to understand it... a lot to do here in terms of documentation and education. 81 | 82 | Dan: Let's use Will's doc for this group's efforts 83 | 84 | (Chatter about licences MDN uses.) 85 | 86 | ## Threat Modeling 87 | 88 | *driving awareness of threats* 89 | 90 | 91 | 92 | ### information addressed to web developers - people building web sites and web applications 93 | 94 | #### use security as one metric by which you choose libraries / frameworks / components 95 | 96 | #### even if you are using frameworks, key topics you need to understand 97 | 98 | 99 | ### information addressed to web framework / library / component developers 100 | 101 | #### Info on what criteria we look for as security guidelines for libraries and frameworks 102 | 103 | * supply chain security - e.g. Scorecard 104 | 105 | #### 106 | 107 | ## Actionable Advice 108 | 109 | 110 | -------------------------------------------------------------------------------- /meetings/2025-08-25-minutes.md: -------------------------------------------------------------------------------- 1 | # SWAG Minutes - Mon 25 August 2025 2 | 3 | Present: William, Aaron, Giovanni 4 | 5 | ## Survey 6 | 7 | Will: Ruth got back to me: "We will need to check with legal in regards to collecting email addresses for follow up interviews. 8 | 9 | The other option is to have the short survey banner displayed but instead of a short survey show a message along the lines of 'We'd love for you to answer a few questions on ... " with a link to the larger survey." 10 | 11 | Will: We (SWAG) still have a responsibility to collect the data in a responsible way 12 | 13 | Prefer an interview over just an extended survey? 14 | 15 | Can we do a test run with a friendly individual to see what sort of questions do well, etc? 16 | 17 | Aaron: What are the questions for the interview test run? 18 | 19 | Will: Just the existing long survey draft but in a more interactive way -- Google Form draft becomes an interview script 20 | 21 | Aaron: Is there an expectation of compensation when we go talk to the general population? Maybe swag? 22 | 23 | Will: MDN Short Surveys are not compensated 24 | 25 | Aaron: But if it's a longer interview? 26 | 27 | Giovanni: 28 | 29 | Collect vs not collect emails: Can the email address collection be optional? Check legal problems. 30 | 31 | MDN hosted vs not: no strong opinions 32 | 33 | Will: Will be very hard to reach back out to people without email addresses? 34 | 35 | Aaron: So not submitting an email is basically declining to interview. Also what are we worried about w.r.t. who is being exposed to legal risk by collecting email addresses? 36 | 37 | Will: Probably the W3C CG 38 | 39 | Aaron: Let's ping Simone to ask about whether there is legal risk for W3C if we as a CG start collecting email addresses for interview. 40 | 41 | Will: Can commit to working on the test run script and finding a subject, we will wait to see what Simone says about legal x W3C CG. 42 | 43 | ## DEFCON 44 | 45 | Giovanni: How was the workshop? 46 | 47 | Aaron: It was good to bring together the attack & defense sides-- feedback along lines of: people have developed webapps but not actually popped one in practice, and also, for those primarly on the attacking side, going through the exercise of deep-diving into a codebase, etc, is novel and forces a holistic thinking of the entire development process. 48 | 49 | Will try to clean up repo & slides and have them point from our CG repo as well. 50 | 51 | ## Firefox x setHtml x TT 52 | 53 | Will: We are coordinating all of the documentation between the different browser vendors as TT / setHtml is landing in Firefox. 54 | 55 | It looks like there isn't great interaction between TT and setHTML 56 | 57 | Aaron: Let's invite some of my colleagues who've been thinking about this for a next call. 58 | 59 | ## SWAG for AI 60 | 61 | Aaron: When we conceived this group-- we thought about guidelines and documentation for *human* developers to write secure code. Now, looking back a couple years later, we see that AI systems are writing a lot of web frontend code-- and possibly a dispropotionate amount (compared to other coding domains, perhaps, because of Canvas buttons, etc). How we should be thinking about extending the scope of our work to not only influence the mindshare of human developers but also so that human+AI generated code is just as safe? We see that dumping a lot of documentation/examples in the context does show a lot of promise in getting out higher-quality code output? 62 | 63 | Giovanni: The prompts are important-- "write me a login page" vs "write me a login page, but also thinking about security" -- do prompts make results that are secure by default? 64 | 65 | Aaron: Does this mean we should also call out how to prompt responsibly in our human developer facing guidelines? 66 | 67 | Giovanni: Secure-by-design principles in the prompt. 68 | 69 | Aaron: Do you want to take a crack at making a PR with these guidelines somewhere in our repo? 70 | 71 | Giovanni: Security prompts for sale in the industry 72 | 73 | Aaron: Is MDN thinking/talking about making docs more ingestible by AI systems? Like one giant markdown doc that concatenates all the pages? 74 | 75 | Will: Probably? 76 | 77 | Will: If you generate the code, do we expect people to always review the code for security guarntees? Is it reasonable to ask for this? Or do we just secure the prompting side and hope for the best? 78 | 79 | Giovanni: We have to use both of them-- ask for secure code to be generated but also always do SAST testing, etc 80 | 81 | Will: Would you trust your agent to write your CSP for you or do you want to go through and inspect it to make sure it's ok? 82 | 83 | Aaron: Cynical take is that some code will still be pushed without being read by humans because a lot of products are pushing vibecoding as a user flow-- also, whether enough people feel empowered with expertise to push back against convincing chatbots 84 | 85 | Will: Maybe something like the HTTPS visual inticator in the browser to show users how secure a site is with CSP/TT? 86 | 87 | Aaron: We've thought about this before, but maybe threat landscape change with the AI-generated code is a good narrative push for why we should reconsider this? 88 | 89 | Will: Also need enough adoption that missing CSP/TT is a rare enough occurence to show in the browser -------------------------------------------------------------------------------- /meetings/2025-09-29-minutes.md: -------------------------------------------------------------------------------- 1 | # SWAG Minutes - Mon 29 September 2025 2 | 3 | Present: Dan, Florian, Will, Giovanni 4 | 5 | ## Plans for survey 6 | 7 | From Simone: [paraphrased] We won't ask for e-mail but we will ask them to join the community group if they would like to be interviewed... 8 | 9 | So what is the next step? 10 | 11 | *we debate whether this will be too much friction* 12 | 13 | Will: alternative - people could respond on social media. 14 | 15 | *we agree to share the survey - and ask people to join the CG if they want to participate in further discussions* 16 | 17 | *Dan to work on text.* 18 | 19 | ## PR 29 Merged 20 | 21 | https://github.com/w3c-cg/swag/pull/29 22 | 23 | Dan: I committed Will's feedback.... 24 | 25 | ## Merge PR 31? 26 | 27 | https://github.com/w3c-cg/swag/pull/31 28 | 29 | Floran : wrote an article about SSRF 30 | 31 | Dan: *leaves positive review* 32 | 33 | *we agree good to merge* 34 | 35 | ## Discussion on Passkeys? 36 | 37 | Will: next thing I want to work on is - authentication - see below - happy to get feedback. I had feedback from Martina - we should really talk about Passkeys - as they are a thing that uses web authentication. She also gave more detail and useful info that I will incorporate into the outline. So updated the outline. 38 | 39 | Dan: Anything for our own guidelines? 40 | 41 | Will: It might be good to use guidelines around authenticaiton... its own section? 42 | 43 | Dan: feels like it should be in security_guidelines.md - as a separate section. 44 | 45 | Florian: there's a new CG on credentials and authentication adopton.. Maybe nice to work together. https://www.w3.org/community/wica/ 46 | 47 | Simone: this group was an idea from webauthn wg... to promote the adoption of web authentication... a web layer for passkeys. The main problem is the developer needs to choose to use it... I have a list of different authenticaiton types - we can use that. We could also talk with Tim C. directly. 48 | 49 | Dan: I suggest we write something ... and then reach out for comment... 50 | 51 | Florian: we are working on MDN.. they are working on microsties - we can still share experience. 52 | 53 | Will: *will file a SWAG issue* I agree having another top level section in security_guidelines... is the right approach. 54 | 55 | ## Concrete Attacks 56 | 57 | From Florian :"What are concrete attacks you expect to be documented for MDN readers? (web developers, library developers, etc.) 58 | The attacks we already have are listed here: https://developer.mozilla.org/en-US/docs/Web/Security/Attacks. 59 | Work in progress articles which we will have soon are: Supply chain attacks, Phishing, IDOR." 60 | 61 | New content in review, feedback appreciated: 62 | - Supply chain attack article: https://github.com/mdn/content/pull/41034 63 | - IDOR attack: https://github.com/mdn/content/pull/41200 64 | - JavaScript Prototype Pollution: https://github.com/mdn/content/pull/41260 65 | - Thanks for the great feedback so far! Will try to work it in the next few days 66 | - Thinking about writing about DOM Clobbering as well 67 | - More? 68 | 69 | Florian: we're writing documentation for concrete attacks... some are still in review... Supply chain attacks is an open PR... Working on prototype pollution... Lots of feedback... One more in review - indirect object reference... 70 | 71 | *discussion on graphql and we agree not to write on this at this time* 72 | 73 | Florian: another topic - DOM clobbering attacks... Nice article from Frederick... Might quality for an MDN article as well... Coming to an end with this work... Soon going to switch to authenticaiton. 74 | 75 | ## Supply chain attacks 76 | 77 | https://github.com/mdn/content/pull/41034 - merge? 78 | 79 | Dan: let me ask for some additional review... from the OpenSSF community. 80 | 81 | *we agree to give Dan a day before merging* 82 | 83 | Simone: [on threat modelling] - one of the discussions with the digital credentials API - they were complaining that I listed threats with them ... one proposal was move to a separate doc "threat model for the web"... I will reference the threats that you already have documented. 84 | 85 | ... we should also talk about "the human web" the threats going to be exploited regarding the human, not only the technical things... 86 | 87 | Dan: examples? 88 | 89 | Simone: e.g. https://www.panmacmillan.com/authors/tim-berners-lee/this-is-for-everyone/9781035023677 - privacy covers covers many but there are some threats missing... e.g. attention hijacking on social networks ... deceptive patterns ... trying to publish a summary of these threat models somewhere. 3 models ... one is technical - e.g. autoplay, infinite scrolling,... there are some technical remediation... also C2PA could be a potential remediation... Article 25 in EU could be a policy remediation... 90 | 91 | Florian: we touched on this a bit - when we wrote about Phishing attacks - also a glossary entry on social engineering... https://developer.mozilla.org/en-US/docs/Glossary/Social_engineering 92 | 93 | Simone: https://www.nirandfar.com/how-to-manufacture-desire/ ... as an example ... 94 | 95 | ## Authentication 96 | 97 | Plan: https://docs.google.com/document/d/1miZbXVjs070J2HH0rsDxqPnUaqNtPP51Uo8d4FU6PTk/edit?tab=t.0 . 98 | 99 | 100 | Please review 101 | -------------------------------------------------------------------------------- /meetings/2024-06-28-minutes.md: -------------------------------------------------------------------------------- 1 | # SWAG-cg call - Fri, 28 June 2024 2 | 3 | Present: Dan Appelquist, Florian Scholz, Jan Kowalleck, Simon Friedberger, Tobie Langel, Dan Veditz 4 | Regrets: Simone Onofri 5 | 6 | https://w3c.github.io/charter-drafts/2024/swag-cg.html 7 | 8 | 9 | Notes: 10 | 11 | - Let's use whereby! 12 | - Intros 13 | - Dan Appelquist 14 | - Tobie langel 15 | - Florian Scholz - what can help us as tech writers to improve technical documentation of security aspects? 16 | - Dan Veditz - co-chair of webappsec - people need to know how to use these specs - 17 | - Jan kowalleck - working in SBOM area - co-lead of cyclonedx sbom standard... working in OWASP 18 | - Simon Friedberger - Mozilla - Security & Cryptopgraphy engineering, member of webappsec 19 | 20 | - Charter: https://w3c.github.io/charter-drafts/2024/swag-cg.html 21 | 22 | - Logistics 23 | - weekly call? too early? 24 | - lets build a critical mass 25 | - lots of people are in central europe 26 | - an hour later would be good for west coast, but not on Fridays 27 | - Mondays 8am PST, 6pm CET? - we agr 28 | 29 | - Discussion of Charter 30 | 31 | Tobie: developer best practices and sub-topics... feels like the work is cut out already... feels very reasonable to me as main focus of the group. to what degree a lot of the work should be getting organized into actually doing it. So what should our deliverables be and what should the way of working be? Maybe easier to work in smaller groups [after we decide that]? How much do we feel collectively that it's clear that we want to work on... 32 | 33 | Tobie: we have received some support from alpha-omega to do some stuff like this for jquery... we didn't get into documentation... beyond jquery. A useful first step would be documenting what currently exists... 34 | 35 | Simon: there is documentation in OWASP and some in MDN... and also defining which of these things we want to do...Specifically, explaining technologies e.g. CSP or providing guides on how to deal with specific threats 36 | 37 | Florian: Will Bamberg's outline for MDN https://docs.google.com/document/d/1p1GtjmTd1uQrO2PRb_uUflAfQpEsfs7hBaopYeuoPMM/edit#heading=h.ck74bmw37a7r 38 | 39 | Dan: Also putting OpenSSF best practices on the pile, e.g. https://best.openssf.org/Concise-Guide-for-Developing-More-Secure-Software 40 | 41 | Tobie: where the documentation is and how easily findable it is... are important. Reports are great but what's better is evergreen content. There should be a structure / process around it to make sure it's sustaibale. 42 | 43 | Simon: https://cheatsheetseries.owasp.org/cheatsheets/Content_Security_Policy_Cheat_Sheet.html and the rest of the series https://cheatsheetseries.owasp.org/index.html 44 | 45 | Tobie: scope is so potentially big - looking at the charter, i resonate with this ... the intersection between security and web. 46 | 47 | Jan: OWASP was that - join of security & web people - we might want to look at these... 48 | 49 | Simon: a lot of this exists but in a very inacccessible format... 50 | 51 | Florian: https://github.com/web-platform-dx/developer-research/blob/main/mdn-short-surveys/2023-05-15-security-dx/interpretation.md survey indicated that a lot of MDN readers find unerstanding the security challenges difficult to understand. Running such a survey again and trying to improve things might be a good idea. Involves talking to them. Better tutorials... etc... 52 | 53 | Jan kowalleck: some OWASP web related projects: (just some examples from [OWASP project list](https://owasp.org/projects/)) 54 | - https://owasp.org/www-project-web-security-testing-guide/ 55 | - https://owasp.org/www-project-vulnerable-web-applications-directory/ 56 | - https://owasp.org/www-project-threat-model/ 57 | - https://owasp.org/www-project-secure-coding-practices-quick-reference-guide/ 58 | - https://owasp.org/www-project-common-lifecycle-enumeration/ 59 | - https://owasp.org/www-project-cheat-sheets/ 60 | - https://owasp.org/www-project-automated-threats-to-web-applications/ 61 | 62 | Dan: https://github.com/ossf/package-manager-best-practices/blob/main/published/npm.md, https://best.openssf.org/SCM-BestPractices/ 63 | 64 | Dan: *about package managers and the web developer workflow* 65 | 66 | Tobie: lots of these terms i don't even know ... there's a gap between security people and others... It would be great if web developers know about the 10 top ones ... and if they never made one of those mistake in the top 10 concerns the security of the web would sky-rocket... 67 | 68 | Jan: *concerns with focusing on top 10 lists* 69 | 70 | Tobie: client side vs back end code ... low naging fruit.. CVEs - half of them are code injection... 71 | 72 | Florian: at the workshop we had one key finding - there is gatekeeping going on in the security world... security experts and only they would know how to make things secure - and that contributes to the fact that front end web developers don't know about security... 73 | 74 | Jan: yes .. have seen that developers don't care about security... but also the industry pushes for that because security is not considered part of job roles... where dedicated people know about security... Secops guy teaches others have to do security... so who are our audience? should we educate font end developers? 75 | 76 | Dan: shift left... we raise the bare on basic security knowledge... 77 | 78 | Tobie: intersection between different roles... e.g. understanding what a threat model is, etc... 79 | -------------------------------------------------------------------------------- /meetings/2024-07-01-minutes.md: -------------------------------------------------------------------------------- 1 | # SWAG CG Call - Mon, 1 July 2024 2 | 3 | ### Present: Dan, Simone Onofri, Florian, Tom Schuster, Simon, Dan Veditz 4 | 5 | 6 | # Introduction 7 | 8 | - Dan 9 | - We'll use the Cyrptpad for minutes, at the end of each meeting I'll move on our GH repo, such as https://github.com/w3c-cg/swag/blob/main/meetings/2024-06-28-minutes.md 10 | - We have the github repo at https://github.com/w3c-cg/swag/ (under W3C CG orga) 11 | - Last week we strated to think about weekly calls and reviewing existing documentation. 12 | - Understand how users and web app developer are going to use these documents 13 | 14 | 15 | - Simone 16 | - connection between specs and web developer - e.g. how to use CSP - also things like xz library attack - 17 | - driving to a safer web 18 | 19 | 20 | - florian - from the survey - web developers find it challenging to understand security threats, the browser security model.... we're working on improving security documentaiton on MDN... Ideal outcome is that people will find it less challenging... that people find it easier to enter this world. 21 | 22 | - dan: beyond the draft charter, how do we organize the work? 23 | 24 | - florian: will from OWD has written a security outline ... 25 | 26 | - dan: do we need a separate document for how to build a component? 27 | 28 | - florian: people write reference documentation on "here is the latest web platform feature and how to use it" but e.g. for CSP you might not even know about it.. We need to explain when do you need these new features. 29 | 30 | - dan: starting from "what are you trying to do"? 31 | 32 | - florian: also - what kind of attacks exist, what are the counter measures... 33 | 34 | - dan: since developers don't currently think security is part of their concerns we should maybe start with an argument about that. 35 | 36 | - florian: same as... 37 | 38 | - dan: vision for what this group is trying to accomplish... 39 | 40 | - dan: then after that ... tying back to user needs and therefore things developers are trying to accomplish to serve user needs... rather than just a list of guidelines... 41 | 42 | - florian: security considerations often talks about what can go wrong... 43 | 44 | - dveditz: slightly contrarian view on security sections in spec - you won't be reading the csp spec security & privacy section unless ou're reading the CSP spec... A bigger problem is how do people know what they need... I like the concise guide - but now as you get deeper "i'm using security x to do this thing"... 45 | 46 | - dveditz: "if you're writing a web applicaiton, what sorts of attacks affect you - input sanitization. output santinization, XSS, CSRF... and then what helps you - e.g. CSP, trusted types, etc... using iframe sandboxes..." what the threats are and dangers are is the big. These problems can befall your web site... 47 | 48 | - Dan: that's an argument for starting with the treat model... 49 | 50 | - dveditz: in a more reference presentation... even if you have people more advanced - they may have heard of XSS, CSRF... some languages have built in... Are we limiting it to "the web" html - a lot of problems are in the server code - and that can be in a variety of languages... 51 | 52 | - Simone: a lot of injection attacks... think about URLs... people don't want to know only what can go wrong but also the solutions... the guidelines must be contextualized... in specific libraries... 53 | 54 | - dveditz: a common issue is pushing things to the client that the server needs to be dealing with... so "don't trust the client" for frameowrks you need to be worrying about higher level things... when people roll their own frameworks - they stuff data into attributes - and then they use a sanitization library that doesn't know about what attributes they're using... that comes up with frameworks because some of the frameworks have magic values... functional things that are in there but are changeable if you're not careful. a sanitizer will strip the onclick handler out of a tag ... but a you migght have a data-something that gets interpreted as a callback and the sanitizer doesn't know to strip it... 55 | 56 | * intro - and vision of what we're trying to achieve 57 | * general threats - common threats 58 | * injection, etc..., 59 | * "pure html, dom, js, CSS" - front end - writing a web site 60 | * threats 61 | * practices and mitigations 62 | * using a framework - front end - writing a web site 63 | * threats 64 | * practices and mitigations 65 | * writing libraries, components, frameworks 66 | * threats 67 | * what happens on the server end - which can be a variety of languages 68 | * threats 69 | * http server configuration 70 | * threats 71 | 72 | - florian: matches a lot of will's proposed structure: https://docs.google.com/document/d/1p1GtjmTd1uQrO2PRb_uUflAfQpEsfs7hBaopYeuoPMM/edit#heading=h.ck74bmw37a7r - also onboarding people into a security mindset - including "security 101"... the theory area of the content... 73 | 74 | - dveditz: a very basic 101 ... then go off to a deeper level of info ... 75 | 76 | - florian: the theory part might be important ... like for CORS... a lot of developers don't know how to deal with this... 77 | 78 | - dveditz: people are designing for the usual customers who are using the web site nicely 79 | 80 | - Simon: i am a big fan of the web security 101 section... the most important is to get people a starting point - the low hanging fruit. explain what the problems might be. 81 | 82 | - dveditz: starting with a simple list like that ... 83 | 84 | ACTION: give feedback on will's document... 85 | 86 | Simon: https://portswigger.net/web-security/dashboard 87 | -------------------------------------------------------------------------------- /meetings/2025-01-13-minutes.md: -------------------------------------------------------------------------------- 1 | # SWAG CG Minutes - Mon 13 January 2025 2 | 3 | Present: Dan, Lola, Will, Aaron 4 | Regrets: Simone 5 | 6 | ## Videos 7 | 8 | *... in progress, Simone to update ...* 9 | 10 | ## Categories for Guidelines 11 | 12 | Will: reviewed the security doc over the weekend and had some qeuesitons... 13 | 14 | > I've been looking at https://github.com/w3c-cg/swag/blob/main/docs/security_guidelines.md and wondering what are good categories to have. The doc currently has "General recommendations", "Front end" and "Back end". Some of them seem strange to me: like I would expect "Back end" to be about server-side implementation, and some are (like validating requests to avoid SSRF) but some are more what I'd think of as "operational" (e.g. enforcing PR review or monitoring for vulnerabilities). 15 | And some that are listed as "Front end" seem questionable to me, like "Prevent injection attacks by validating and sanitizing user inputs" - I don't think this can be confined to the front end. 16 | Some practices, such as output encoding/using a good template library, might be front end or back end depending on your architecture. 17 | I wonder if there are really two categories: 18 | > - "**Security features**" (things you might need your site to implement), like HTTPS, CSP, input sanitization 19 | > - "**Security practices**" (practices your team needs to follow), like PR review, MFA for devs, monitoring vulnerabilities. 20 | 21 | Will: ... whether these are good categories and whether the categories have the right things in them... and things we might want to have on the list. Some things are not clearly front end or back end... E.g. XSS mitigations... 22 | 23 | Dan: happy with that. 24 | 25 | Aaron: I think the front end/back end is traditionally a distinction people care about but is this still in fashion? We should use the actual language people use. 26 | 27 | Dan: open SSF is coming from a cloud background so their self-identification might be different 28 | 29 | Lola: 2 - first thing is - another approach of categorizing based on what part of the web architecture you want to secure... client / server ... reasoning I have is that if I'm a web developer and I'm searching for good security practices ... another thing - you mentioned you have a security practice and - is the implementation the same depending on where in the architecture it is... 30 | 31 | Will: from what I know - what you're doing is the same but the tools are slightly different. e.g. using something like react vs. something like django. 32 | 33 | Lola: a combination of the two would be my preference. Having it as features and practices is too general but similar issue with front end/ back end... I do think it's context specific... there should be an easy way to distinguish what comes out of the box vs. what I need to write code form. 34 | 35 | Will: makes sense. Will: is client/server a synonym for front-end/back end? 36 | 37 | Dan: In privacy docs we had labels, could do this for security too? 38 | 39 | Aaron: with server-side rendering with angular / etc... client-side vs. server-side gets more fuzzy... 40 | 41 | *we discuss the nuance between code that will be executed on the client (whcih may be initially generated on a server) vs. code that executes on the server to serve API requests* 42 | 43 | Lola: I'm still seeing that distinction of front end / back end engineers... 44 | 45 | Will: MDN traditionlally says "MDN is just about front end" - it's less the case... on the other side there are a lot of client side frameworks... 46 | 47 | Dan: maybe "configuration management" is a third category? 48 | 49 | Aaron: I think the *tag* system would help with that... we could attach both tags... 50 | 51 | Will: Happy to try this approach... 52 | 53 | Aaron: Tags could overlap... aligned with how developers see themselves... *front end* / *back end* / *dev ops* ... 54 | 55 | ### authentication 56 | 57 | Will: we need something with authentication... does it fit into a taxonomy.... 58 | 59 | Will: feels like it's its own category .. because it fits together 60 | 61 | Will: I will add authetication features. 62 | 63 | ### other... 64 | 65 | Will: secure cookie settings. trusted types we should have in here... using templating engines... sort of touched on here but could go into more detail... something about CSRF ... 66 | 67 | Lola: do we want to say anything AI and the web here? People use AI generated code on the web ... especially as they copy & paste code they don't understand ... AI is a kind of a black box ... should we have a note "be careful when copying code from AI"... common possible issues that generated code might have. 68 | 69 | Dan: I like this but... want it to be actionable. 70 | 71 | Will: the action could be "enforce PR review" and even say "especially if code is generated by AI" 72 | 73 | Lola: agree... also: if we put this under PR reviewing... assumes that everyone is creating in a community ... some developers are independent... 74 | 75 | Dan: we could encourage developers to use a code analysis like dependabot... 76 | 77 | Aaron: https://w3c.github.io/webappsec/mitigation-guidance/ brain dump ... CSRF protections et.c.. because it's published undwe W3C banner... a quick blurb about each of these features... Having some of these materials referenced or distilled somewhere else would be good.... 78 | 79 | Lola: good idea - like WPT and webdx... 80 | 81 | Aaron: other big - could we take over the stewardship of this from webappsec... 82 | 83 | Will: I've seen it ... I see everything through prism of MDN.. I see this as something that can be reflected on MDN... 84 | 85 | Lola: for a different project, in the a11y space, I was trying to manage data between MDN and w3c... but if content moves from w3c to MDN, licensing issues come up. Also: as best as possible, if there is one source of data - one place to update - it's better. It's a good idea for MDN to have the content ... 86 | 87 | ### Libraries.... 88 | 89 | Aaron: working on a PR... CSP and Trusted types... More sanitary coding practices... writring code safealy... 90 | -------------------------------------------------------------------------------- /docs/guidelines_for_libraries.md: -------------------------------------------------------------------------------- 1 | # Security Guidelines for Framework & Library Developers 2 | 3 | Similarly to our [Security guidelines for web application developers](./security_guidelines.md), we want the authors of frameworks and libraries that will be used as dependencies to be as careful as possible to not introduce potential vulnerabilities (or code that can be chained into a vulnerability when combined with user code). 4 | 5 | We want to be more careful about the security standards in code here, due to the fact that their reach is not limited to just the single application being authored but potentially to thousands of applications across the ecosystem that use these as dependencies or less-visible transitive dependencies. 6 | 7 | ## Security Features 8 | 9 | ### Ensure compatibility for users to allow them to enforce a strict Content Security Policy (CSP) 10 | 11 | A [CSP](https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP) helps mitigate cross-site scripting (XSS) and other code injection attacks by specifying which sources of content are trusted. For the best protection against many variants of XSS, we recommend an approach known as a [strict CSP](https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP#strict_csp), which uses a nonce or hash to restrict the scripts that can load. 12 | 13 | This means that the code introduced to applications through your dependency cannot rely on features blocked by a strict CSP, such as: 14 | 15 | - Inline event handlers 16 | - `javascript:` URLs 17 | - `eval()` calls 18 | 19 | which must be refactored, as suggested in [this guide](https://web.dev/articles/strict-csp#refactor). 20 | 21 | ### Limit the use of potentially unsafe DOM APIs to minimize injection risk and ensure compatibility with Trusted Types 22 | 23 | Using [unsafe DOM APIs](https://www.w3.org/TR/trusted-types/#dom-xss-injection-sinks) that can turn untrusted user strings into HTML markup executing on the page may lead to injection vulnerabilities, such as XSS. 24 | 25 | Furthermore, if the user of your dependency wants to enforce [Trusted Types](https://web.dev/articles/trusted-types) as a defense against XSS, they will run into incompatibilities with using the [Trusted Types API](https://developer.mozilla.org/en-US/docs/Web/API/Trusted_Types_API), since the [Trusted Types policies](https://developer.mozilla.org/en-US/docs/Web/API/Trusted_Types_API#trusted_type_policies) have to be invoked at the site of assignment into the [injection sinks](https://developer.mozilla.org/en-US/docs/Web/API/Trusted_Types_API#injection_sinks), which will be in the dependency's code rather than the application's code. 26 | 27 | The recommendation is to 28 | 29 | 1. Refactor away any unnecessary calls to these unsafe DOM APIs if possible 30 | 2. Create your dependency's Trusted Types policy and clearly document the policy name, as in [this example](https://angular.dev/best-practices/security#enforcing-trusted-types). 31 | 32 | ### Publish your library with provenance using trusted builders 33 | 34 | [Software attestations](https://slsa.dev/attestation-model) help protect against supply chain attacks. Since [NPM supports package provenance](https://github.blog/security/supply-chain-security/introducing-npm-package-provenance/), you can use [trusted builders](https://slsa.dev/blog/2023/05/bringing-improved-supply-chain-security-to-the-nodejs-ecosystem) to let your customers know that the package that they are importing has been built using the code in the repository using trusted builders. 35 | 36 | ## Security Practices 37 | 38 | The following security practices apply just as they do for [our guidelines for web application developers](./security_guidelines.md). 39 | 40 | ### Evaluate the security metrics of open source libraries 41 | 42 | When selecting open source libraries, frameworks, build tools, or similar, take into account open source security best practices. 43 | 44 | This helps ensure that the libraries you use are actively maintained and have a good security track record, reducing potential vulnerabilities in your application. Consider the following [Scorecard](https://securityscorecards.dev) metrics: _tbd_ 45 | 46 | ### Require multi-factor authentication for project developers 47 | 48 | Ensure all developers working on the project are using multi-factor authentication (MFA) to access the source repository. 49 | 50 | Multi-factor authentication adds an additional layer of security by requiring more than one form of verification, reducing the risk of unauthorized access to your codebase. 51 | 52 | - [openssf concise guide](https://best.openssf.org/Concise-Guide-for-Developing-More-Secure-Software) 53 | 54 | ### Have a documented security policy 55 | 56 | Document (in a `SECURITY.md` file) your security policy, including how you want people to notify you of security issues. A clear security policy fosters transparency and encourages responsible disclosure of vulnerabilities, allowing you to address issues promptly and maintain user trust. 57 | 58 | - [openssf concise guide](https://best.openssf.org/Concise-Guide-for-Developing-More-Secure-Software) 59 | 60 | - ### Use package managers such as NPM to automatically manage dependencies and enable updates 61 | 62 | Package managers streamline the process of managing libraries and dependencies, ensuring that you can easily update to the latest versions, which often include important security patches. 63 | 64 | - [openssf concise guide](https://best.openssf.org/Concise-Guide-for-Developing-More-Secure-Software) 65 | 66 | ### Monitor known vulnerabilities in your web app's direct & indirect dependencies 67 | 68 | Regularly checking for vulnerabilities in both direct and transitive dependencies helps you stay informed about potential security risks and take action to mitigate them. [openssf concise guide](https://best.openssf.org/Concise-Guide-for-Developing-More-Secure-Software) 69 | 70 | ### Keep dependencies up to date 71 | 72 | Keeping dependencies (i.e., libraries, polyfills, frameworks, etc.) up to date minimizes the risk of exploitation through known vulnerabilities. Regular updates should be part of your development lifecycle. 73 | 74 | - [openssf concise guide](https://best.openssf.org/Concise-Guide-for-Developing-More-Secure-Software) 75 | 76 | ### Enforce a code review policy 77 | 78 | Implementing a code review process helps catch potential security issues before they are merged into the main codebase, creating a culture of security awareness among developers. 79 | 80 | - [openssf concise guide](https://best.openssf.org/Concise-Guide-for-Developing-More-Secure-Software) 81 | -------------------------------------------------------------------------------- /meetings/2024-09-09-minutes.md: -------------------------------------------------------------------------------- 1 | # SWAG CG Call Minutes - 9 September 2024 2 | 3 | Present: Dan Appelquist, Randall T. Vasquez, Thomas Preece, Will Bamberg, Aaron Shim, Okiki Ojo 4 | 5 | ## Intros 6 | 7 | Thomas: security architect... we have a security champions network... we do a lot of internal training, etc... a big part is giving the right info so people can code applications securely... 8 | 9 | ## should MDN (and web.dev for that matter) consistently recommend "strict CSP" (i.e. using nonce/hash rather than allowlist)? 10 | 11 | Will: got some interesting feedback on slack.. I've read various things that recommend strict CSP.. 1 reason: it's a lot easier (allow lists can get huge), 2nd: it's more secure (allowlists can be hard to het right)... But MDN doesn't talk about this. Deb.dev does have a good guide... but the main CSP guide doesn't mention strict CSP... 12 | 13 | Aaron: from google perspective.. alignment between what MDN suggests... and google focused channels... would be very much in favour. Would reduce ambiguity. 2 angles - strict CSP is better - yes - some debate - but value to aligning messaging in this space - that should be a meta goal. Other data point : for the CSP protections we use at google we use strict non-space CSPs... the allow lists don't have the level of security we require... 14 | 15 | Okiki: what custom CSPs do you use? 16 | 17 | Aaron: the CSPs we configure are ... avoiding allow-lists CSPs... if you go t a big google client and look at what the headers are - that is representative of what we use in production... sometimes we use allow-lists - so we can get violation reports... to see what strange domains people are including scripts for... 18 | 19 | Okiki: I think the tooling is lacking right now... 20 | 21 | Aaron: the nonces are only good if you use it once... tricky thing about nonces is it needs to be back-end and front-end compatible... in a place where we don't have control of back end we use a hash-based CSPs... I can link some items in the meeting notes... We're looking at making the tooling more smooth... 22 | 23 | Will: sounds like there might be different opinions of recommending strict? Are there people who think this isn't a good idea? 24 | 25 | Aaron: from google pov we don't want to assume that all will take our technical arguments ... but I agree that most folks are clear on the limits of the other approach... so I hope it's not contraversial... 26 | 27 | Will: I think the OWASP guidance is close to that as well... The conservative thing on MDN is to not be opinionated... 28 | 29 | Randall: hard to give out over-arching guidance because there are a lot of legacy applications... From OWASP ideology - it would flow from the threat model. No single rule that applies everywhere. Think about how the complexity of the web ends up impacting your threat model. 30 | 31 | Dan: I think that's in our wheelhouse. 32 | 33 | Will: e.g. openwebdocs.org doesn't have a CSP... should every one has a CSP? just saying "everyone should do it" doesn't make sense. 34 | 35 | Aaron: Always a balance of ... usually for static web sites that don't deal with user data maybe there is less at stake vs. something like gmail for instance. I imagine there is something on OWASP that talks about this. 36 | 37 | Randall: ASVS has something... 38 | 39 | Okiki: from a developer perspective - I know of a number of developers being bitten by CSPs. - certain APIs like shared array buffers - in order to use those you need a CSP but you can get bitten if you're not careful. So there's production CSPs vs developer CSPs. 40 | 41 | Thomas: getting a CSP policy in ... production systems .. can be difficult because of all the dependencies... A massive wall that some people come across. 42 | 43 | Will: I understand that the strict CSPs... it's a lot easier to maintain... That seems like a big point in its favor... 44 | 45 | Randall: right now the recommendation is to start with relaxed and then gradually move up. 46 | 47 | Thomas: we had different CSP policies in development ... but then mismatches with production. 48 | 49 | Aaron: we like to keep our dev mode and prod mode CSPs as close as possible - because you want them to break in dev mode ... We're missing tooling ... 50 | 51 | Will: next step will be to file and issue in MDN and link back to issue here... 52 | 53 | ## federated identity 54 | 55 | Will: I'm working on a guide explaining how to implement authentication using a federated identity system. I have some idea for what to talk about, but I'd love pointers for things we ought to cover here. 56 | 57 | Will: I'm working on docs on authentication using different authentication mechanisms... will talk about passwords, one-time-passwords, mfa, federated identity... this relates back to the web security outline... there's not anything on MDN about this... Want to talk about IDPs, 3rd parties, underlying technologies... Also want to walk through the practice of it... As far as I can see - a lot of this is provider specific... feels more helpful to refer to particular providers... so which provider should we talk about? google identity services... 58 | 59 | Dan: noting https://www.w3.org/reports/identity-web-impact/ 60 | 61 | Thomas: have you factored in the privacy concerns around external providers? E.g. using facebook ... 62 | 63 | Will: yep. 64 | 65 | Okiki: a couple tools that help developers accomplish this... next auth ... [?]... a set of applications they support by default ... they use those by defaults because it's easiest to create oauth apps for those... could also connect to pre-existing tools - open source tools - ... to jump over the preferential treatment thing... https://next-auth.js.org/ https://lucia-auth.com/ https://authjs.dev/ 66 | 67 | Thomas: those libraries... also you tend to see oauth type proxies... and typically pass headers up to the back-end server..... Can be easier but slightly more brittle. 68 | 69 | Dan: and fedCM? 70 | 71 | Will: one thing about fedcm is that it helps to make things less privacy-invasive... We should talk about fedcm... the cm API documentation... we'd like to say "use fedcm" though it's only supported by chromium at the moment... we ought to say we want people to be heading to fedcm... I know browsers are positive about it and will ship... don't know dev ecosystem view... the idea is that it pushes the mechanics into the browser... that helps with privacy presrvation... 72 | 73 | Okiki: with regards to FedCM - why would developers want the browser to take control of the authentication process... 74 | 75 | Dan: ...[holds forth on FedCM] 76 | 77 | Okiki: would be wise to have docs on access control lists... etc... controling access to the applicaiton... should MDN also cover that? 78 | 79 | Will: ideally yes but that would be a separate thing... I also wondered if google phasing out 3rd party cookies... will have an impact on fedcm... 80 | 81 | Thomas: I've also seen a fair few companies just run a whole instance of something like KeyCloak as their identity provider (which also has federated options) 82 | 83 | Randall: awsome write-up on authentication... 84 | 85 | Okiki: how oauth works fom a spec perspective that would be pretty cool.. 86 | 87 | Randall: from a docs perspective .. I've more generally seen auth split into 2 parts - gaining access and auth and matintaining that access... 88 | 89 | Will: also fades into session management... 90 | 91 | ## Talk for SOSS Community Day 92 | 93 | Dan: working on [slides here](https://docs.google.com/presentation/d/18iOsWdh_LG_gqUdSW7XfE5UOoB6_Zfi_B2XDDurPRUc/edit#slide=id.p) 94 | 95 | ## Discussion of open issues 96 | 97 | ### [Work item: come up with a set of security criteria for packages](https://github.com/w3c-cg/swag/issues/1) 98 | 99 | ### [Security Features List](https://github.com/w3c-cg/swag/issues/2) 100 | 101 | ### [How can we help CSP gain more adoption with Web Developers](https://github.com/w3c-cg/swag/issues/3) 102 | 103 | ## AOB 104 | 105 | ### JSR 106 | 107 | Okiki: becoming popilar with with developers... JSR has found this niche... would that be a connection worth making? They currently follow what NPM does ... if you publish the packages on github they can track the exact build... but they might need... 108 | 109 | -------------------------------------------------------------------------------- /meetings/2024-07-22-minutes.md: -------------------------------------------------------------------------------- 1 | #SWAG CG Call - 22 July 2024 2 | 3 | Present: Dan, Jan, Josh Grossman, Florian, Aaron Shim, Simone Onofri, Tobie 4 | 5 | ## Intros 6 | 7 | Josh: working on OWASP guidelines document - ASVS () 8 | 9 | Aaron: work on web security on google properties - looking to share some experiential knowledge from our remediations projects in adopting web security features 10 | 11 | Florian: lead open web docs - open collective for technical writers working on MDN and other open projects. Project issue https://github.com/openwebdocs/project/issues/198 and content outline https://docs.google.com/document/d/1p1GtjmTd1uQrO2PRb_uUflAfQpEsfs7hBaopYeuoPMM/edit 12 | 13 | Simone: security lead of w3c - working in webapp sec and interested in helping developers implement these specs... 14 | 15 | Tobie: run a small consultancy - i'm the technical lead for the eclipse foundation... effort for CRA. looking at legisltative side. Also on board and CPC of OpenJS Foundation. 16 | 17 | Jan: was part of secure the web fwd, works on OWASP [CycloneDX](https://cyclonedx.org/)... 18 | 19 | ## Google Web Security Team 20 | 21 | Aaron: our team has experience deploying features that webappsec has done. Developers often have trouble understanding how to go from the spec - to something that delivers a measurable benefit. Some of the efforts we have been working on - we've published some blog posts... on google security engineering blog : 22 | 23 | https://bughunters.google.com/blog/6037890662793216/enabling-trusted-types-in-a-complex-web-application-a-case-study-of-appsheet 24 | 25 | ... details a case study of adoption of trusted types. Less straightforward... 26 | 27 | ... big picture: we want to publish more contact like this and have guides like this in more neutral places - possibly on MDN etc... make it easier for developers who have heard about CSP or Trusted Types - to get step by step guidelines on how to integrate. On open source tooling, we are seeing if we can make tooling to automate some of the processes, make it easier for developers - specifically something called [CSP Evaluator chrome extension](https://chromewebstore.google.com/detail/csp-evaluator/fjohamlofnakbnbfjkohkbdigoodcejf?pli=1) - this is an extension you can click around and it tells you about CSP configuration issues - presents in UI with suggestions. Another suggestion - is static analysis engine for JS and TypeScript - published as an ESLint plug-in. Gives remediation suggestions. 28 | 29 | ... so we are interested in more documentation and any tool we can contribute to to make this more actionable. 30 | 31 | Simone: helping developers with CSP is something important; threat model for the web platform would also be useful - for web developers & spec developers. Could be used in w3c. For example I received a request from vibration API - needs a security review - just having a threat model that is published in one place could be useful. 32 | 33 | Aaron: we did a bit of a doc ... [we pushed a couple of markdown files](https://github.com/w3c/webappsec/pull/639) to webappsec - this describes what the webappsec features is supposed to protect against. 34 | 35 | https://w3c.github.io/webappsec/mitigation-guidance/ 36 | 37 | ## ASVS / OWASP 38 | 39 | Josh: one of the challenges is developers say "how do I secure an application"? no one answer. We have the OWASP top 10 - not comprehensive and not super-actionable. ASVS is a bit higher level... 40 | 41 | ... Also we have the OWASP cheat sheets project... () 42 | 43 | ... Also [OpenCRE](https://www.opencre.org/) - intended to act as a reference between these projects (as displayed in the [OWASP Application Security Wayfinder](https://owasp.org/projects/#owasp-projects-the-sdlc-and-the-security-wayfinder))... common weakness enumeration... could also be a useful resource. 44 | 45 | ... Important to have that high level baseline... where I can see the full picture and where I want to dive deeper. If there are any questions involving OWASP, I'm happy to help make links. OWASP is also not connected to one particular organization... Just ask to be aware of overlaps to make sure there is linking rather than duplication... 46 | 47 | Also wanted to mention another related initiative: 48 | 49 | Daniel: 50 | Important that there is linking between documents and resources 51 | Key point is not where resources are hosted but how they are shared/publicised (@Daniel: Did I understand this correctly) 52 | Shared terminology to avoid confusion 53 | 54 | ... Eclipse foundation has initiatives as well... 55 | 56 | ## Discussion 57 | 58 | Josh: Open Regulatory Compliance working group in Eclipse? 59 | 60 | Tobie: yes. Regulation is at a high level asking for the industry to express its best practices and standards so they can be turned into "official" standards that can be refered to by legislation. The focus is broader and it's more about supply chain than web applications... web apps mostly fall outside the scope of the CRA... and tie into NISE legislation which is for SAAS. 61 | 62 | Aaron: what things are floaring around.. certs, tooling and protocls in the supply chain security space... to mark dependencies as OK or not OK... The crux of the problem is - visibility - developers will pay attention to protocls that get surfaced or tooling... 63 | 64 | Dan: OpenSSF has some automation around it so it does have that niche, but maybe some neutrality around pushing people in one direction 65 | 66 | Josh: openssf has quick wins to capure certain things - but some things are non-automatable - e.g. Static analysis tools can scan for problems but they are not good for scanning for authentication problems as they are specific to the application. It's important to have the baseline. 67 | 68 | Tobie: one question - the space is big - the question that I have is have we decided where to focus - intersection of different points of the field? Should we be 101 for certain cases... how do we fit? 69 | 70 | Florian: back to the outline that will shared - i agree to link to OWASP resouces and google resources - but also with MDN we have an opportuntiy to bring education to where developers hang out already. There is no security area on MDN itself where we can education web developers on web security. Educating developers on MDN ... meet them where they already are. There are people who want to learn about security - they will need some hand holding - then people who are using an API and they need a heads-up for that specific API, on how to mitigate attacks for use of that API. 71 | 72 | Dan: We also need to prioritize on the threats we actual have, helping developers with their actual concerns, starting understanding the threats. 73 | 74 | MDN short survey: https://github.com/web-platform-dx/developer-research/blob/main/mdn-short-surveys/2023-05-15-security-dx/interpretation.md 75 | 76 | ## Post Spectre ... 77 | 78 | Simone: there was a discussion at webapp sec working group about the Post-Spectre Web Development https://www.w3.org/TR/post-spectre-webdev/ 79 | 80 | Dan: e.g. sharedarray buffer improvements... 81 | 82 | Tobie: how much is developer facing? My understanding was that developers that were succeptile were removed or mitigated and as a result this is mostly implementer concerns rather than info? 83 | 84 | Josh: underlines - we need to figure out who to target - 85 | 86 | Dan: we have discussed audience as web developers - including framework developers - 87 | 88 | Tobie: In Alpha-Omega, that matches the JavaScript framework Web developer - if you change something on jQuery or React, the impact is massive. It might be interesting to be conscious of this. At one point (e.g.) AMP blocked people from using synchronous IO. similar strategies... 89 | 90 | ... being specific about what and where... even in "user land" JS land in the browser. 91 | 92 | Dan: *Our target* are **web developers** (not browser developers or specs developers) and also **web developers working on frameworks and libraries** 93 | 94 | ... action on all to read MDN docs and also the link shared by Aaron: 95 | 96 | - https://bughunters.google.com/blog/6037890662793216/enabling-trusted-types-in-a-complex-web-application-a-case-study-of-appsheet 97 | - https://w3c.github.io/webappsec/mitigation-guidance/ 98 | -------------------------------------------------------------------------------- /docs/security_guidelines.md: -------------------------------------------------------------------------------- 1 | # Guidelines for developing more secure web applications 2 | 3 | ## Security features 4 | 5 | This category lists web platform features that you can implement in a web application to help mitigate or respond to various attacks. 6 | 7 | ### Use HTTPS 8 | 9 | Ensure your web application uses [HTTPS](https://developer.mozilla.org/en-US/docs/Glossary/HTTPS) (HTTP over [TLS](https://developer.mozilla.org/en-US/docs/Glossary/TLS)) for all its pages and other resources that it loads. Implementing HTTPS is crucial for securing data in transit. It protects against eavesdropping and man-in-the-middle attacks. 10 | 11 | To support HTTPS a web application needs a TLS certificate. [Let's Encrypt](https://letsencrypt.org/) is a widely used nonprofit Certification Authority which issues free TLS certificates. 12 | 13 | Not all TLS configurations are equally secure: if you need to configure your own server, consult a resource such as Mozilla's [TLS Recommended Configurations](https://wiki.mozilla.org/Security/Server_Side_TLS#Recommended_configurations). 14 | 15 | Modern web hosting services support HTTPS for you, either by default or through a configuration setting. In this situation, the hosting service is likely to manage your certificate and configure the server on your behalf. 16 | 17 | You should serve all pages over HTTPS, not just pages that you consider especially sensitive. 18 | 19 | When a page loads resources (scripts, stylesheets, fonts, images, and so on), these resources should also be served over HTTPS. If a page is loaded over HTTPS and it attempts to load resources over HTTP, then the browser will either try to upgrade the load request to use HTTPS or will block the request: this is called [mixed content blocking](https://developer.mozilla.org/en-US/docs/Web/Security/Mixed_content). 20 | 21 | If it's not possible for you to update your code to load resources from HTTPS URLs (for example, because your HTML has been archived) you can include a [content security policy](https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP) that contains the [`upgrade-insecure-requests`](https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP#upgrading_insecure_requests) directive, and the browser will automatically upgrade these requests to HTTPS. 22 | 23 | To support clients which request pages over HTTP, you can listen for HTTP requests and use a [301 Moved Permanently](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/301) response to redirect to the HTTPS version. If you do this, then you should also send the [HTTP `Strict-Transport-Security`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Strict-Transport-Security) (HSTS) response header: this informs clients that you wish them to use HTTPS, and will cause the browser to connect using HTTPS directly for any subsequent visits, even those made using HTTP URLs. 24 | 25 | #### Learn more 26 | 27 | - [Let's Encrypt](https://letsencrypt.org/) 28 | - [TLS Recommended Configurations](https://wiki.mozilla.org/Security/Server_Side_TLS#Recommended_configurations) (Mozilla) 29 | - [Transport Layer Security Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Transport_Layer_Security_Cheat_Sheet.html) (OWASP) 30 | - [HTTP Strict Transport Security Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/HTTP_Strict_Transport_Security_Cheat_Sheet.html) (OWASP) 31 | - [Strict-Transport-Security](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Strict-Transport-Security) (MDN) 32 | 33 | ### Implement a content security policy (CSP) 34 | 35 | A CSP helps mitigate [cross-site scripting (XSS)](https://developer.mozilla.org/en-US/docs/Web/Security/Attacks/XSS) and other code injection attacks by specifying which resources a document is allowed to load. A CSP can also help control whether a page can be embedded in another page, thus protecting against [clickjacking](https://developer.mozilla.org/en-US/docs/Web/Security/Attacks/Clickjacking), and can help ensure that all resources are loaded over HTTPS. 36 | 37 | - To mitigate against XSS, we recommend that you implement a [strict CSP](https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP#strict_csp), which uses a [nonce](https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP#nonces) or a [hash](https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP#hashes) to indicate to the browser which scripts it expects to see in the document. However, any CSP that prevents uncontrolled execution of inline scipts is much better than none. 38 | 39 | - To enforce the use of trusted types, set the [`require-trusted-types-for`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/require-trusted-types-for) directive. See the [Validate and sanitize user input](#validate-and-sanitize-user-input) guideline. 40 | 41 | - To defend against [clickjacking](https://developer.mozilla.org/en-US/docs/Web/Security/Attacks/Clickjacking), set the [`frame-ancestors`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/frame-ancestors) directive. 42 | 43 | - To help ensure that all resources are loaded over HTTPS, set the [`upgrade-insecure-requests`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/upgrade-insecure-requests) directive. See the [Use HTTPS](#use-https) guideline. 44 | 45 | #### Learn more 46 | 47 | - [Content Security Policy guide](https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP) (MDN) 48 | - [Content Security Policy Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Content_Security_Policy_Cheat_Sheet.html) (OWASP) 49 | - [Strict CSP guide](https://web.dev/articles/strict-csp) (web.dev) 50 | 51 | ### Set the SameSite attribute on sensitive cookies 52 | 53 | The [`SameSite`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Set-Cookie#samesitesamesite-value) cookie attribute is a defense in depth against a variety of attacks, including [clickjacking](https://developer.mozilla.org/en-US/docs/Web/Security/Attacks/Clickjacking), [CSRF](https://developer.mozilla.org/en-US/docs/Web/Security/Attacks/CSRF) and various [cross-site leaks](https://xsleaks.dev/). It takes one of three values: `Strict`, `Lax`, or `None`. 54 | 55 | The strictest value is `Strict`, which prevents the cookie from being included in any cross-site requests: that is, any requests which originate from a different [site](https://developer.mozilla.org/en-US/docs/Glossary/Site) from the site that set the cookie. 56 | 57 | However, this will prevent the cookie being included in some cross-site requests for which you might want it. For example, if the user is logged into your site, and the user then clicks a link to your site from a different site, you probably want to show the logged-in version of your page, and for this to happen the request must include the user's cookie. 58 | 59 | The `Lax` value is intended to allow for this use case, but offers correspondingly weaker protection against cross-site attacks. 60 | 61 | As a general guide, then, you should try to use `Strict` for some cookies and `Lax` for others: 62 | 63 | - `Lax` for cookies that you will use to decide if a logged-in user should be shown a page 64 | - `Strict` for cookies that you will use to authorize requests that change the server's state, such as transferring money or changing the user's settings. 65 | 66 | Note that `Lax` is the default value in some but not all browsers, and in those browsers, the implementation of `Lax` when it is the default is more permissive than the normal implementation of `Lax`. This means that you should actively set `Lax`, and not rely on it being the default. 67 | 68 | #### Learn more 69 | 70 | - [`SameSite`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Set-Cookie#samesitesamesite-value) (MDN) 71 | - [SameSite cookies explained](https://web.dev/articles/samesite-cookies-explained) (web.dev) 72 | - [Bypassing SameSite cookie restrictions](https://portswigger.net/web-security/csrf/bypassing-samesite-restrictions) (PortSwigger) 73 | 74 | ### Use Fetch metadata to defend against cross-site attacks 75 | 76 | Many attacks, including [CSRF](https://developer.mozilla.org/en-US/docs/Web/Security/Attacks/CSRF) and some [cross-site leaks](https://xsleaks.dev/), depend on an attacker's site making an HTTP request to the target site: that is, making a cross-site request. 77 | 78 | Fetch metadata headers are a collection of HTTP request headers which provide information about the context of an HTTP request. Fetch metadata headers include: 79 | 80 | - [`Sec-Fetch-Site`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Sec-Fetch-Site): Whether the request is same-origin, same-site, or cross-site. 81 | - [`Sec-Fetch-Mode`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Sec-Fetch-Mode): The request's [`mode`](https://developer.mozilla.org/en-US/docs/Web/API/Request/mode). 82 | - [`Sec-Fetch-User`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Sec-Fetch-User): Whether the request is a user-initiated navigation. 83 | - [`Sec-Fetch-Dest`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Sec-Fetch-Dest): The request's [`destination`](https://developer.mozilla.org/en-US/docs/Web/API/Request/destination). 84 | 85 | When handling a request, a server can examine these headers, and use them to reject certain cross-site requests, and so defend against the corresponding attacks. 86 | 87 | To protect against CSRF attacks, you should understand where your site is implementing HTTP requests that change the server's state in a significant way (for example, transferring the user's money), and should consider using Fetch metadata headers to prevent these requests from being made cross-site. 88 | 89 | To protect against certain cross-site leaks, you should decide whether you need other sites to be able to load your site's resources, and either block cross-site loads entirely or only allow them for allowlisted sites. This is called a _Resource Isolation Policy_. 90 | 91 | #### Learn more 92 | 93 | - [Defend against CSRF using Fetch metadata](https://developer.mozilla.org/en-US/docs/Web/Security/Attacks/CSRF#fetch_metadata) (MDN) 94 | - [Protect your resources from web attacks with Fetch Metadata](https://web.dev/articles/fetch-metadata) (web.dev) 95 | - [Isolation Policies](https://xsleaks.dev/docs/defenses/isolation-policies/) (xsleaks.dev) 96 | 97 | ### Implement monitoring and logging 98 | 99 | Implement effective monitoring and logging to detect and respond to security incidents. 100 | 101 | Monitoring and logging are essential for identifying suspicious activities and responding to incidents in a timely manner. This practice helps in forensic analysis and improving overall security posture. 102 | 103 | - [openssf concise guide](https://best.openssf.org/Concise-Guide-for-Developing-More-Secure-Software) 104 | 105 | ### Validate and sanitize user input 106 | 107 | Input validation and sanitization are critical for preventing injection attacks, such as SQL injection and [cross-site scripting (XSS)](https://developer.mozilla.org/en-US/docs/Web/Security/Attacks/XSS). Ensuring that user inputs conform to expected formats helps mitigate these risks. 108 | 109 | To mitigate SQL injection attacks, use [prepared SQL statements with parameterized queries](https://cheatsheetseries.owasp.org/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet.html). This ensures that the user input is treated as data rather than SQL commands. 110 | 111 | To mitigate XSS attacks: 112 | 113 | - When interpolating input into a page as text, use a reputable templating engine that performs input encoding, and understand the context in which you are interpolating input. 114 | - When interpolating input as HTML, sanitize it using a reputable library such as [DOMPurify](https://github.com/cure53/DOMPurify). If you're rendering input in the client using DOM APIs like [`innerHTML`](https://developer.mozilla.org/en-US/docs/Web/API/Element/innerHTML), use the [Trusted Types API](https://developer.mozilla.org/en-US/docs/Web/API/Trusted_Types_API) along with the [`require-trusted-types-for`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/require-trusted-types-for) CSP directive, to ensure that input is being passed through a sanitization function. 115 | 116 | #### Learn more 117 | 118 | - [SQL Injection Prevention Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet.html) (OWASP) 119 | - [Cross-site scripting (XSS)](https://developer.mozilla.org/en-US/docs/Web/Security/Attacks/XSS) (MDN) 120 | - [Trusted Types guide](https://web.dev/articles/trusted-types) (web.dev) 121 | - [Trusted Types API](https://developer.mozilla.org/en-US/docs/Web/API/Trusted_Types_API) (MDN) 122 | 123 | ### Implement restrictions on framing 124 | 125 | Controlling whether your site can be embedded in another site using an [`