J’ai du mal à comprendre ou est la faille chez Facebook ici.

On est dans le cas d’une autorisation OAuth, l’utilisateur accorde la permission a NameTests d’accéder aux resources de l’utilisateur, c’est la faute à NameTests si ils font n’importe quoi avec les données (et éventuellement à l’utilisateur d’accepter n’importe quel scope).

De plus, NameTests ne devrait jamais autoriser des sources autres que celles bien définies à interroger son endpoint, il existe un protocole qui s’appelle CORS (Cross-Origin Resource Sharing) qui existe et qui n’est pas la pour décorer. Il est sensé limiter quel domaine à le droit d’appeler cet endpoint. Ainsi un site malveillant qui aurait un js qui appelle cet endpoint pour aspirer les données devrait se voir refuser la requête par n’importe quel navigateur un peu récent.

Mais bon, c’est toujours plus facile de taper sur FB plutôt que sur les “startups”/webagencies en mousse qui font des trucs putaclick créés par des pseudos stagiaires incompétents attirés par l’appat du gain.

Non, désolé l’analogie ne fonctionne pas. Tout le système OAuth se base sur le consentement explicite de l’utilisateur qui décide si l’éditeur de l’application a le droit d’accéder aux resources. C’est un système de procuration et délégation.

Personellement, je ne donne pas de procurations sur mon compte bancaire à des personnes en qui je n’ai pas confiance. Je croise un gars dans la rue qui me le demande, je lui refuse. Et bien sur Facebook, c’est pareil, les seules applications que j’autorise sont celles d’éditeurs en lesquels je fais confiance (ou bien je révoque immédiatement après l’utilisation) et uniquement avec les scopes qui me semblent appropriés.

Ici, ce serait se plaindre que ta banque a laissé quelqu’un à qui tu as fourni une procuration sur ton compte, vider tes comptes alors que tu lui avais octroyé pour qu’il s’achète une baguette. (Même si en vrai c’est un peu plus compliqué car FB impose des règles sur l’utilisation des données)