In the vast majority of cases integration is by the including a script controlled by the advertising network in the page they are advertising on.
So for the purposes of the browser security model, the script already runs in the domain of the host site. It can directly read any non-HttpOnly cookies, and can make any request it likes using XMLHttpRequest to APIs on the host site using the user's cookie without relying on CORs.
The only very minor difference between first and third party script inclusion is access to HttpOnly cookies (depending on the cookie scoping).
Both of the first party script inclusion approaches have mitigations available to the host site: in the proxy approach, the server could filter the cookies before proxying. In the CNAME approach, taking care with cookie scoping could solve the problem. Careless adoption is likely to open security flaws under both techniques.
Correct. Authentication should always be via cookies with "HttpOnly" set, since (a) the cookie is not needed client side and (b) it somewhat limits the damage XSS can do.
So for the purposes of the browser security model, the script already runs in the domain of the host site. It can directly read any non-HttpOnly cookies, and can make any request it likes using XMLHttpRequest to APIs on the host site using the user's cookie without relying on CORs.
The only very minor difference between first and third party script inclusion is access to HttpOnly cookies (depending on the cookie scoping).
Both of the first party script inclusion approaches have mitigations available to the host site: in the proxy approach, the server could filter the cookies before proxying. In the CNAME approach, taking care with cookie scoping could solve the problem. Careless adoption is likely to open security flaws under both techniques.