In my ASP.NET Web application, i have made the below changes to make the ASP.NET_SessionID and .ASPXAUTH Cookies Secure by adding the below entries to web.config
<httpCookies httpOnlyCookies="true" requireSSL="true" />
<forms requireSSL ="true" />
Cookie flags, like Secure and HttpOnly, are only sent from the server to the client. You won't ever see them in traffic going the other way. If you want to make sure that a cookie is Secure, have the browser make a request over HTTP (instead of HTTPS) and see if the cookie is still present (it shouldn't be). If you want to make sure a cookie is HttpOnly, open your site in the browser and then check the value of
document.cookie using the JS console in the dev tools; you should see any non-httponly cookies you have but no httponly cookies.
Cookies are an inherently client-side thing. They are a way for a server to tell the client "every time you make a request to me, include this bit of info". The Secure flag modifies that to say "Every time you make a request to me over a secure connection, include this bit of info (but don't ever divulge it over insecure connections)". A conforming user agent - that is to say, a web browser - is supposed to obey those directives. However, there are no equivalent directives the other way; servers don't have to do anything at all with cookies the client sends them, and there is no "client sets a cookie on the server" equivalent of the way servers can set cookies on the client. Directives (including Secure, HttpOnly, Domain, Expires, etc.) are only used when setting a cookie.