Fix typos in the Appendix section

docs/ADR-014-Cardano-API-WASM-library-for-browser.md

@@ -195,11 +195,11 @@ If we do a stateful API (e.g., for a "virtual wallet"), the state can be managed
 Developing a JavaScript/TypeScript API for Cardano by compiling `cardano-api` to WASM is very feasible and we can make it easy and frictionless for the user. We must make sure to keep it simple, stable, and test all the user flows. We also should ensure we use pure Haskell as far as possible to take advantage of HLS as much as possible, and we can try to automate as much of the glue layer generation as possible. We should also provide TypeScript types for the API to both make it easier (through auto-complete documentation) and safer (through types) for users to develop using the API. And we should ensure compatibility with the different workflows and consistency through the use of CI whenever possible.
 
 
-## Appendix: **CORS and SOP explained.**
+## Appendix: **CORS and SOP explained**
 
-SOP (or Same Origin Policy) is a restriction that is enforced by browsers to protect both users and server from potential attacks from malicious web applications to other web applications or APIs unless they opt out. In our particular case, a service that offers a public API would be protected by SOP because a random JS application wouldn't be able to access it directly from the user browser (i.e: the user's computer). Instead, the app would be forced to access the API from the backend of the JS application, and that helps security because the source for the request is specifc to the app (the app server), and:
-  - It can blocked if the API is abused.
-  - It cannot pass as the user (because the request won't include the user's cookies, for example).
-Additionally, if SOP was not in place, a very popular but malicious website could easily include a JS snippet that causes every visitor of the malicious website to silently make costly requests against a victim API, and that would potentially work out as DDOS (Distribute Denegation of Services) attack, by consuming lots of resources from the victim API.
+SOP (or Same-Origin Policy) is a restriction that is enforced by browsers to protect both users and servers from potential attacks from malicious web applications to other web applications or APIs unless they opt out by using CORS (Cross-Origin Resource Sharing), which is a mechanism that lets servers allow web applications to circumvent the Same-Origin Policy restriction. In our particular case, a service that offers a public API would be protected by SOP because a random JS application wouldn't be able to access it directly from the user's browser (i.e: the user's computer). Instead, the app would be forced to access the API from the backend of the JS application, and that helps security because the source for the request is specifc to the app, since it is done from the app's backend server. And the requests from that server:
+  - Can easily be blocked if the API is abused.
+  - Cannot pass as the user (because the request won't include the user's cookies, for example).
+Additionally, if SOP was not in place, a very popular but malicious website could easily include a JavaScript snippet that would cause every visitor of the malicious website to silently make potentially costly requests against a victim API, and that would potentially work out as DDOS (Distribute Denegation of Services) attack, by consuming lots of resources from the victim API.
 
-Unfortunately this means that JS cannot access public API's unless those API's use CORS to lift SOP restrictions. This ADR suggests that there could potentially exist a service like [Koios](https://koios.rest/) that does this, as long as it can be guaranteed that the queries offered by the API are made in a way that is efficient enough, and user supplantation is made impossible or not applicable.
+Unfortunately, this means that JavaScript cannot access public API's unless those API's use CORS to lift SOP restrictions. This ADR suggests that there could potentially exist a service like [Koios](https://koios.rest/) that does this, as long as it can be guaranteed that the queries offered by the API are made in a way that is efficient enough, and user supplantation is made impossible or not applicable.