Security/Features/XSS Filter
Once you have created your Feature page, please remove this paragraph and link to your page from the Features Inbox, where a team will triage it and move it into the appropriate Feature list. If you have any questions, please contact Deb.
Feature | Status | ETA | Owner |
XSS Filter | Testing feasibility. | 2011-09-01 | Sid Stamm |
Summary
This feature provides resistance from reflected XSS attacks -- these are the attacks where a malicious person inserts script into a URL, and a vulnerable page reflects the contents of the URL into a page (where the script is run). A filter can identify patterns in the URL and block them from being executed as script on the page.
Team
Who's working on this?
- Feature Manager: Sid Stamm
- Lead Developer: Riccardo Pelizzi
- Product Manager:
- QA:
- Security: Curtis Koenig
- Privacy: Sid Stamm
Team list should make it clear who to ask about what, and who to ping when they're needed. If you do not need someone in a particular role (ie: Security), that's fine, just delete that line. Contact info for each person would also be handy.
Release Requirements
Complete checklist of items that need to be satisfied before we can call this feature "done".
Next Steps & Open Issues
Either the next set of tasks that need to happen to move this project along, or (ideally) the full list of project tasks/action items with things crossed off as they're finished. Including the name of who's responsible for each item, and a rough ETA can be useful.
Open issues include unanswered questions, things that need to be explored, decisions that still need to be made, etc. Again, including the name of who's responsible for each item can be useful.
Related Bugs & Dependencies
Links to the feature tracking bug & other relevant bugs; links to related plans (test plan, product marketing plan, etc.); notes about things that depend on this, etc.
Risks
Identify, prioritize, track and communicate any risks associated with this feature/project.
Use Cases
Everyone loves use cases, so you should provide them if you can (and where it makes sense). The Channel Switcher Feature Page has some good examples.
Designs
Any and all mockups, design specs, tech specs, etc. Either inline or linked to.
Test Plans
Any and all test plans and strategies. Either inline or linked to.
Goals
The high level goals for the feature (which the release requirements checklist should fulfill). These are the guiding light and overall vision for the feature. Refer to this if there is confusion or are disputes about direction, designs, planning, etc.
Non-Goals
Things we are specifically not doing or building as part of this feature.
- This feature will not stop persistent or injected XSS attacks (only reflected ones).
Other Stuff
Can include things like:
- Competitive landscape
- Research & references
- Whatever else is useful to the project.
Legend (remove if you like)
Healthy: feature is progressing as expected. | |
Blocked: feature is currently blocked. | |
At Risk: feature is at risk of missing its targeted release. | |
ETA | Estimated date for completion of the current feature task. Overall ETA for the feature is the product release date. |
Please remove this line and any non-relevant categories below. Add whatever other categories you feel are appropriate.