Add test coverage for actix-web, poem, and http-types cookie secure attribute

[Copilot]

Expands CWE-614 test coverage to include three additional Rust web frameworks that handle HTTP cookies.

Changes

Added dependencies to options.yml:

• actix-web = { version = "4", features = ["cookies"] }
• poem = { version = "3", features = ["cookie"] }
• http-types = { version = "2", features = ["cookies"] }

Added test functions in main.rs:

• test_actix_web() - Uses actix_web::cookie::Cookie::new() + set_secure()
• test_poem() - Uses poem::web::cookie::Cookie::new_with_str() + set_secure()
• test_http_types() - Uses http_types::Cookie::new() + set_secure()

Each test validates three cases: secure explicitly false, secure explicitly true, and secure left as default.

fn test_actix_web() {
    use actix_web::cookie::Cookie as ActixCookie;

    // secure set to false
    let mut cookie1 = ActixCookie::new("name", "value");
    cookie1.set_secure(false); // $ Source
    println!("actix-web cookie1 = '{}'", cookie1.to_string()); // $ Alert[rust/insecure-cookie]

    // secure set to true
    let mut cookie2 = ActixCookie::new("name", "value");
    cookie2.set_secure(true); // good
    println!("actix-web cookie2 = '{}'", cookie2.to_string());

    // secure left as default
    let cookie3 = ActixCookie::new("name", "value"); // $ Source
    println!("actix-web cookie3 = '{}'", cookie3.to_string()); // $ Alert[rust/insecure-cookie]
}

Updated test expectations:
Regenerated CookieSet.expected, InsecureCookie.expected, and Cargo.lock via codeql test run . --learn.

Warning

Firewall rules blocked me from connecting to one or more addresses (expand for details)

I tried to connect to the following addresses, but was blocked by firewall rules:

• docs.rs
  • Triggering command: curl -s REDACTED (dns block)

If you need me to access, download, or install something from one of these locations, you can either:

• Configure Actions setup steps to set up my environment, which run before the firewall is enabled
• Add the appropriate URLs or hosts to the custom allowlist in this repository's Copilot coding agent settings (admins only)

Original prompt

Add test cases to rust/ql/test/query-tests/security/CWE-614/main.rs for setting secure / insecure cookies with following Rust libraries:

• actix-web
• poem
• http-types

We probably want three test cases for each one:

• creating a cookie with the secure attribute set to true
• creating a cookie with the secure attribute set to false
• creating a cookie with the secure attribute left as default

If there's are multiple significantly different ways of using a library we might want additional test cases, but we don't want test cases for every edge case (like we do for the cookie and biscotti libraries) - we're pretty happy with the way this query works now and are simply looking to expand coverage to more libraries with a minimum of fuss.

Please add the new dependencies in the options.yml file (in the same directory as main.rs), so that our test runner can run the test successfully. You can run the test as follows:

1. download and extract CodeQL CLI: cd /tmp && curl -L -o codeql-linux64.zip https://github.com/github/codeql-cli-binaries/releases/latest/download/codeql-linux64.zip && unzip -q codeql-linux64.zip
2. add to PATH: export PATH="/tmp/codeql:$PATH"
3. from the test directory, codeql test run . --learn.

This will generate the Cargo.toml file, regenerate Cargo.lock, build and analyze the test code, and modify the .expected file for the test. You can accept all of these changes. Interpretting the results is not part of this task, as long as the test does compile under the test runner.

---

✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.

[geoffw0]

Looks good at a glance. I will have a closer look tomorrow.

[geoffw0]

I've pushed some updates to the tests. The actix and http_types tests already pass - presumably because they bring in code that we already model. So I think I'll have a go at adding models for poem to this pull request.

[geoffw0]

Added new models, fixed a path duplication issue. Ready for review.

Note that the PR title doesn't represent this new work - we are now improving models (and logic) as well as tests.

[Copilot]

Pull Request Overview

This PR adds support for detecting insecure cookies in three additional Rust web frameworks: actix-web, poem, and http-types. The changes extend the existing CWE-614 query to handle cookie creation and configuration patterns in these frameworks.

Key Changes:

• Extended test coverage to include actix-web, poem, and http-types cookie handling
• Modified the query's barrier logic to use isBarrierIn instead of isBarrier
• Added new dependencies to the test suite for the three frameworks

Reviewed Changes

Copilot reviewed 6 out of 7 changed files in this pull request and generated 2 comments.

Show a summary per file

File	Description
rust/ql/test/query-tests/security/CWE-614/options.yml	Added dependencies for actix-web, poem, and http-types
rust/ql/test/query-tests/security/CWE-614/main.rs	Added test functions for the three new frameworks
rust/ql/test/query-tests/security/CWE-614/InsecureCookie.expected	Updated expected query results with new test cases
rust/ql/test/query-tests/security/CWE-614/CookieSet.expected	Updated expected cookie set tracking results
rust/ql/test/query-tests/security/CWE-614/Cargo.lock	Added transitive dependencies for the new crates
rust/ql/src/queries/security/CWE-614/InsecureCookie.ql	Changed barrier from isBarrier to isBarrierIn
rust/ql/lib/change-notes/2025-11-05-poem.md	Added change note for poem support

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[geoffw0]

DCA LGTM. This is ready for approval.

[paldepind]

Looks good! My only comment is a question.

[paldepind]

Is this change because setting a cookie's security to false is a sink, and hence we want to make false a barrier as well, as otherwise two sources would flow to a sink?

What is the isBarrier -> isBarrierIn change for?

[geoffw0]

Yes, it's about preventing excessive flows in a case such as this:

set_secure(false); // source
set_secure(false); // source
sink();

Making line 2 a barrier prevents flow from line 1 to 3, leaving us with just the shorter path from line 2 to 3. It's a fairly common pattern to make sources in-barriers, e.g. you'll see this in all of the rust/cleartext-* queries.

The reason I've changed it to an in barrier is simple - if I didn't, then flow from every source would be blocked immediately by that source itself being a barrier. As an in-barrier, the situation becomes something like this:

|barrier| set_secure(false);
|barrier| set_secure(false); -> flow ->
sink();