One Article Review
| Source |  GoogleSec |
|---|---|
| Identifiant | 8493538 |
| Date de publication | 2024-04-23 13:15:47 (vue: 2024-05-04 12:06:53) |
| Titre | Découvrir des menaces potentielles à votre application Web en tirant parti des rapports de sécurité Uncovering potential threats to your web application by leveraging security reports |
| Texte | Posted by Yoshi Yamaguchi, Santiago Díaz, Maud Nalpas, Eiji Kitamura, DevRel team
The Reporting API is an emerging web standard that provides a generic reporting mechanism for issues occurring on the browsers visiting your production website. The reports you receive detail issues such as security violations or soon-to-be-deprecated APIs, from users\' browsers from all over the world.
Collecting reports is often as simple as specifying an endpoint URL in the HTTP header; the browser will automatically start forwarding reports covering the issues you are interested in to those endpoints. However, processing and analyzing these reports is not that simple. For example, you may receive a massive number of reports on your endpoint, and it is possible that not all of them will be helpful in identifying the underlying problem. In such circumstances, distilling and fixing issues can be quite a challenge.
In this blog post, we\'ll share how the Google security team uses the Reporting API to detect potential issues and identify the actual problems causing them. We\'ll also introduce an open source solution, so you can easily replicate Google\'s approach to processing reports and acting on them.
How does the Reporting API work?
Some errors only occur in production, on users\' browsers to which you have no access. You won\'t see these errors locally or during development because there could be unexpected conditions real users, real networks, and real devices are in. With the Reporting API, you directly leverage the browser to monitor these errors: the browser catches these errors for you, generates an error report, and sends this report to an endpoint you\'ve specified.
How reports are generated and sent.
Errors you can monitor with the Reporting API include:
Security violations: Content-Security-Policy (CSP), Cross-Origin-Opener-Policy (COOP), Cross-Origin-Embedder-Policy (COEP)
Deprecated and soon-to-be-deprecated API calls
Browser interventions
Permissions policy
And more
For a full list of error types you can monitor, see use cases and report types.
The Reporting API is activated and configured using HTTP response headers: you need to declare the endpoint(s) you want the browser to send reports to, and which error types you want to monitor. The browser then sends reports to your endpoint in POST requests whose payload is a list of reports.
Example setup:# |
| Notes | ★★★ |
| Envoyé | Oui |
| Condensat | reporting 2024 Devrel Díaz Eiji Kitamura Maud Nalpas Santiago Yamaguchi Yoshi `default` `main ability able above abstract accepts access accompanied across acting action actionable activated actual actually addressed addresses administrators advanced advantage agent agents aggregates aggregation algorithm algorithms all allowed allows also alternative alternatives: although always ambient analyzing another antivirus any apache api apis application application: applications approach approximate architecture are article aside assist attach attempting authentication authored automatically available away base baseline bases basis beam because been before behavior being believe benefits besides better between bigtable bits blockedurl blog blogpost bots boxes break browser browsers browsers: bug build builds but bytes calls can cannot capabilities capture capturing case cases catches caused causes causing centralized challenge challenges changes changing chrome circumstances classes client cloud clusters code codebase coding coep collect collected collecting collector column come comfortable common company compatible compiled components conditions confidence confident configured consequence consider constellations contain contained content contents converts cookies coop coop/coep could counting covering crash crawlers created creep cross csp csv current custom cycle dangerous data datadog declare default= degree demo: demonstrates depending deploy deployed deploying deprecated deprecation described describes detail detailed details detect developed developers developing development devices devtools diagram: differ different differs difficult digest directly distill distilling distinguishing document documented documenturl does doesn doing dom don during each easily effectively elements embedder emerging employees enables end endpoint endpoint: endpoint; endpoint;# endpoint;document endpoint= endpoint`content endpoints endpoints: enforce enforced enforcing engineer engineering engines ensure entire entity equivalent error errors errors: establish etc even event events every example example/default example/main execute executes explained explicit extension extensions extracts fault features fetch fetched field fields file files filter filtering filters finding first fixing flag focus focused following following: forbidden forbids format fortunately forwarder forwarding framework from full fully fundamental fuzzy gather gauge general generate generated generates generic get given google great green group grouped grouping groups handle handler handlers handles happens hard has have header; headers: help helpful helping helps here high highly hint hints: hope how however http https://reports hundreds hunters hyperloglog identified identify identifying illustrated implement important include include: included including incompatible individual industry information ingestion inject injected inline input insights instance instructions instructs interested interesting interventions introduce introduced invasive investigate issues iterate javascript json just keep key known large lead leaked learning let leverage leveraging lifetime like likely line lines link linked list listed load loads locally locations long look made main make makes malware many map maps march massive matches may means mechanism metadata might minimized mitigations mix mixed mobile mode monitor monitoring more most motivate moz must need networks nevertheless new newer nightly noise noisy non none not note note: number numbers object occur occurring occurs often one only open opener operate options origin other out outlining over overview own packaged page pages panel panel: partially particular parts party paths patterns payload per permissions piece pieces pipeline pipeline: platform platforms plenty point points policies policy policy: possible post posted posture potential potentially preferred prefixes prerequisites previous pricing principle prioritize problem problem: problems process processed processes processing processor production products project |
| Tags | Malware Tool Vulnerability Mobile Cloud |
| Stories | |
| Move | 
|
L'article ne semble pas avoir été repris aprés sa publication.
L'article ne semble pas avoir été repris sur un précédent.