El problema de JSON que llevó a Google a anteponer while fue un desglose del mismo origen en las primeras versiones de Firefox (1.5 y 2b específicamente) donde el archivo JSON podría cargarse como una etiqueta de script normal desde fuera del sitio, y Sus datos son accesibles.
Normalmente, los archivos JSON no "le dicen" al motor JS que haga nada si se carga como un script, por lo que no tienen / dejan ninguna referencia a sus estructuras de datos. La seguridad de JS se basa en referencias, por lo que el supuesto está bien. Los literales de objetos de JSON ( {} ) son en realidad una ambigüedad para el motor de JS, ya que parecen llaves de código, lo que provoca un error de sintaxis. El problema con el FF anterior era que se podían usar modificaciones de tiempo de ejecución poco claras que hacían que los literales de Array ejecutaran algún otro código cuando se analizaban o creaban. Ese otro código podría alcanzar introspectivamente el contenido de la matriz, que fue un error.
Hubo problemas relacionados con XML, ya que Firefox consideraba que algunas formas XML eran JavaScript válido (tm) usando la extensión E4X de FF (Ecmascript4XML). IE tuvo algunos problemas con el contenido no js que se cargaba como una secuencia de comandos, error, pero que revelaba el contenido a un controlador de errores globales aplicado previamente, que informaba de la fuente del "código" que causaba el problema.
Dado que ahora existen formas seguras y viables de capturar contenido JSON remoto, las vulnerabilidades de los navegadores obsoletos y las vulnerabilidades JSONp / eval() ya no se aplican a la carga de contenido. Si intenta cargar un recurso JSON válido como un script, no puede acceder al contenido de otro JS.
Por último, no creo que esto tenga mucho que ver con la seguridad; php, curl, python, etc. no dan ninguna información sobre las reglas del navegador; Si los datos están ahí fuera, está ahí fuera. Lo único que hace la política del mismo origen en ese sentido es evitar el robo de recursos de datos no secretos ".