“non-HttpOnly Cookie”本身并不是漏洞。
“HttpOnly cookie”可以降低XSS攻击的风险。也就是说，任何攻击者将脚本注入您的网站，将无法获取此cookie的值，从而保护会话。
如果您的应用程序需要使用Cookie值作为标头添加，则不能将此Cookie标记为“HttpOnly”。您可以更改请求处理程序，以便在Cookie中而不是在标头中查找该值（这样您就可以设置标记），但这可能会使您的网站面临CSRF的风险。最安全的方法是让您的处理程序通过“HttpOnly”cookie检查授权，并在报头中使用另一个标记值（“non-HttpOnly”）来检查CSRF。如果这些值不同，例如在加密令牌模式或同步器令牌模式中，则攻击者仅通过XSS检索一个值没有多大价值，因为他们不能使用它来授权请求。请注意，任何XSS漏洞通常比CSRF漏洞问题更大，因为攻击者总是可以使用他们的XSS攻击来直接从您的站点提交请求，但这是一个更难完成的攻击。至少使用“HttpOnly”，他们无法从您的站点获取auth cookie来远程登录。
您提到的另一个cookie标志是secure flag。这将把cookie的作用域限制为https连接，如果您使用https（也是推荐的），建议您这样做。但这不会影响JavaScript是否可以访问该值。
如果您确实使用了“non-HttpOnly cookie”，那么您仍然可以通过以下方式减轻XSS的威胁。
1.将所有脚本代码移到外部js文件中，并设置Content Security Policy以防止执行任何内联脚本。
1.确保在输出时对所有用户输入进行了正确编码（例如，<在HTML中变为<），并对应用程序运行Web安全扫描程序。

如果您没有标记HTTPOnly，您的用户仍然比其他情况下更容易受到XSS的攻击，因为cookie仍然可以从JavaScript访问。（在HTTPOnly标记的情况下，Cookie会随每个请求（包括 AJAX 调用）一起发送，以检索身份验证信息。

有一种混合的方式来做这件事。我说混合是因为它涉及到你所做的一半和bksi在评论中提到的混合。
由于我不知道您的完整场景，所以这个答案假设您只是在寻找一种方法，在允许用户进行更改或启动进程服务器端之前验证用户;登录、查看帐户页面等等。你永远不应该仅仅依赖httpOnly = false我建议你将它与下面的内容一起使用。

固体解决方案

当用户成功登录时设置一个普通的cookie，这不需要通过HTTPS发送，虽然这会很好。这个cookie应该是一个随机生成的令牌。我通常哈希（在PHP中使用md5加密）他们的用户ID（假设你使用数据库）和他们登录的时间戳。这确保了令牌是唯一的。
现在你有一个令牌作为cookie保存在他们的本地机器上，同时确保将这个令牌保存在服务器端的PHP会话中。现在任何时候他们访问一个页面或发送一个 AJAX 请求，你都可以将本地cookie与服务器端的PHP会话值进行比较。这是验证与你的服务器交互的用户的最快方法。如果值匹配，他们就是合法的。
这并不是完全安全的。本地cookie总是可以被编辑，这是我们通常不太关心的事情，因为这只会通过使用户的会话无效来伤害用户。另一方面，狡猾的黑客可以改变PHP会话，这可能使其他用户无效，因为他们的会话被删除或劫持。黑客必须获得合法的会话令牌，并制作一个cookie来匹配。

更好的解决方案

1)在服务器端，你可以使用数据库来代替PHP会话。过程保持不变，但现在你需要做更多的工作来保持数据库中的会话表是最新的。通常，这是通过保存带有时间戳的令牌并在每次检查令牌时更新这个时间戳来完成的。如果令牌被检查，而最后一个时间戳真的很旧（由您决定时间长度）您可以通过销毁用户的本地cookie并让他们重新登录来取消对用户的身份验证。但这会占用更多的资源，并且会降低具有大量流量负载的站点的速度。
2)使用一种双重身份验证的形式。对于简单的事情，这将在90%的时间使用PHP会话，但当出现一个极其重要的过程时，比如更新个人信息或提供信用卡信息，检查数据库。2这需要在用户机器上保存两个不同的cookie。3一个是检查PHP会话的身份验证，另一个是检查数据库。这种情况下，黑客很难突破到更重要的事情，因为他们需要弄清楚令牌和数据库，一个是不容易窃取。

最后的想法

这是一个相当安全的答案，但是你仍然应该实施额外的安全预防措施。你最近的评论听起来像你使用cookie和 AJAX 倒退，但也许我误解了。以下是我如何做到这一点：

[User]-> Tries logging in to website with a login form
[Server]-> Checks this information against the database Pass, log 'em in.
[Server]->  Generate and set a random token as a cookie

我在这里使用PHP，并且通常用sessionToken这样的名字来存储这个cookie。这个cookie现在立即存在于用户的计算机上，我们，服务器，总是可以在服务器端访问它;我们可以在任何时候调用它。但是这并不安全，因为人们可以在我们发送cookie给他们的时候，在对方不知道的情况下复制/窃取cookie。我稍后会处理这个问题。
[服务器]-〉创建PHP会话（会话ID：abc123）服务器端的所有令牌。
这是安全性的第一步。PHP会话不容易被窃取或黑客攻击。因此，即使有人窃取了我们用户的令牌cookie，当他们试图在他们的计算机上使用它时，它也会失败。下面是一个有效的用户：

[User]-> (PHP session id: abc123) Tries to access secured page or content. PHP session is called up and is checked against the cookie token. If they equal each other this attempt passes.

在这里，用户在他们不知道的服务器上有一个会话，该会话可以识别他们是谁，并且只能由服务器访问;通常是这样。这时你的 AJAX 请求就开始发挥作用了。每当用户试图做一些你想看看他们是否被允许做的事情时，就通过AJAX向一个PHP脚本发送一个请求来验证用户。它所做的只是返回PASS或FAIL。然后你就可以使用AJAX或Javascript来做你需要做的任何事情。下面是一个黑客示例：

[Hacker]-> Steals a cookie from a user over a cafe's wifi.
[Hacker]-> Tries to access the website you are on with it.
[Server]-> (PHP session id: ???) Doesn't have one, destroy the cookie and ask this user (the hacker) to login again.

这是我能给予的最多的信息和帮助。你最近的评论开始听起来像是你应该在Stackoverflow上发布的新问题。