{
    "api_version": "1",
    "kind": "dse_post",
    "self": "https://update.dsesecurity.com/api/v1/posts/restrict-who-can-supply-aws-session-tags-used-for-authorization/",
    "item": {
        "id": "https://update.dsesecurity.com/updates/restrict-who-can-supply-aws-session-tags-used-for-authorization/",
        "slug": "restrict-who-can-supply-aws-session-tags-used-for-authorization",
        "url": "https://update.dsesecurity.com/updates/restrict-who-can-supply-aws-session-tags-used-for-authorization/",
        "alternate_urls": {
            "markdown": "https://update.dsesecurity.com/updates/restrict-who-can-supply-aws-session-tags-used-for-authorization.md",
            "json": "https://update.dsesecurity.com/api/v1/posts/restrict-who-can-supply-aws-session-tags-used-for-authorization/"
        },
        "title": "Restrict who can supply AWS session tags used for authorization",
        "summary": "Treat permission-bearing session attributes as controlled inputs.",
        "format": {
            "slug": "guide",
            "name": "Guide"
        },
        "priority": {
            "slug": "info",
            "name": "Information"
        },
        "featured": false,
        "image": {
            "theme": "cyber-defense",
            "label": "Cyber defense",
            "alt": "Layered glass and metal cyber-defense structure with controlled blue and gold signal paths.",
            "card_url": "https://update.dsesecurity.com/assets/editorial/cyber-defense-card.webp?v=1.8.20",
            "hero_url": "https://update.dsesecurity.com/assets/editorial/cyber-defense-hero.webp?v=1.8.20",
            "social_url": "https://update.dsesecurity.com/assets/editorial/cyber-defense-social-v2.jpg?v=1.8.20",
            "width": 2400,
            "height": 1350
        },
        "topics": [
            {
                "slug": "cybersecurity",
                "name": "Cybersecurity",
                "url": "https://update.dsesecurity.com/topic/cybersecurity/"
            },
            {
                "slug": "it",
                "name": "IT",
                "url": "https://update.dsesecurity.com/topic/it/"
            }
        ],
        "author": {
            "name": "DSE Security Editorial Team",
            "url": "https://update.dsesecurity.com/#editorial-team",
            "type": "Organization"
        },
        "publisher": {
            "name": "Detection Systems & Engineering",
            "url": "https://dsesecurity.com/"
        },
        "published_at": "2026-10-20T18:13:32+00:00",
        "modified_at": "2026-10-20T18:34:28+00:00",
        "reviewed_on": "2026-10-20",
        "reading_minutes": 2,
        "word_count": 248,
        "potentially_affected": "Apply this to AWS attribute-based access workflows that rely on session tags, including federated role sessions.",
        "dse_recommendation": "DSE recommends listing the attributes that influence access and identifying the trusted system permitted to supply each one.",
        "primary_source": {
            "name": "AWS Documentation",
            "url": "https://docs.aws.amazon.com/IAM/latest/UserGuide/id_session-tags.html",
            "published_on": null,
            "authority": "docs.aws.amazon.com"
        },
        "publishing_principles": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/",
        "usage_info": "https://update.dsesecurity.com/usage/",
        "copyright_notice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.",
        "content_html": "<p>Treat permission-bearing session attributes as controlled inputs.</p>\n<h2>Source facts</h2>\n<p>AWS STS can pass session tags and mark selected keys as transitive through role chaining. Relevant role trust policies need sts:TagSession permission. Session tags can override matching tags, and AWS provides conditions to constrain tag keys, values and transitive keys. Tags are therefore part of the authorization design.</p>\n<p>Source: <a href=\"https://docs.aws.amazon.com/IAM/latest/UserGuide/id_session-tags.html\">AWS Documentation</a>.</p>\n<h2>Applicability</h2>\n<p>Apply this to AWS attribute-based access workflows that rely on session tags, including federated role sessions.</p>\n<h2>DSE recommendation</h2>\n<p>DSE recommends listing the attributes that influence access and identifying the trusted system permitted to supply each one. Constrain acceptable keys and values in the role trust design instead of allowing callers to assert any department or project. Review whether a tag must survive the next role assumption. Keep authorization attributes separate from free-form reporting labels, and assign responsibility for updating the mapping when the organization changes. Review conflicts between inherited and newly supplied tags before rollout. Include a deliberately conflicting attribute in the design review and write down which source should be authoritative. Have the identity and resource owners agree the expected access result before any test, rather than accepting whichever value appears in a successful session.</p>\n<h2>Verification</h2>\n<p>Proposed verification: assume a disposable role with an allowed attribute, a disallowed value and an unexpected transitive key. Follow the intended role chain and confirm the resulting access. Inspect both trust decisions and resource authorization rather than checking only whether a tag appears.</p>\n<h2>Official reference</h2>\n<p><a href=\"https://docs.aws.amazon.com/IAM/latest/UserGuide/id_session-tags.html\">AWS Documentation</a>. Reviewed October 20, 2026.</p>",
        "content_text": "Treat permission-bearing session attributes as controlled inputs.\nSource facts\nAWS STS can pass session tags and mark selected keys as transitive through role chaining. Relevant role trust policies need sts:TagSession permission. Session tags can override matching tags, and AWS provides conditions to constrain tag keys, values and transitive keys. Tags are therefore part of the authorization design.\nSource: AWS Documentation.\nApplicability\nApply this to AWS attribute-based access workflows that rely on session tags, including federated role sessions.\nDSE recommendation\nDSE recommends listing the attributes that influence access and identifying the trusted system permitted to supply each one. Constrain acceptable keys and values in the role trust design instead of allowing callers to assert any department or project. Review whether a tag must survive the next role assumption. Keep authorization attributes separate from free-form reporting labels, and assign responsibility for updating the mapping when the organization changes. Review conflicts between inherited and newly supplied tags before rollout. Include a deliberately conflicting attribute in the design review and write down which source should be authoritative. Have the identity and resource owners agree the expected access result before any test, rather than accepting whichever value appears in a successful session.\nVerification\nProposed verification: assume a disposable role with an allowed attribute, a disallowed value and an unexpected transitive key. Follow the intended role chain and confirm the resulting access. Inspect both trust decisions and resource authorization rather than checking only whether a tag appears.\nOfficial reference\nAWS Documentation. Reviewed October 20, 2026.",
        "content_markdown": "Treat permission-bearing session attributes as controlled inputs.\n\n## Source facts\n\nAWS STS can pass session tags and mark selected keys as transitive through role chaining. Relevant role trust policies need sts:TagSession permission. Session tags can override matching tags, and AWS provides conditions to constrain tag keys, values and transitive keys. Tags are therefore part of the authorization design.\n\nSource: [AWS Documentation](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_session-tags.html).\n\n## Applicability\n\nApply this to AWS attribute-based access workflows that rely on session tags, including federated role sessions.\n\n## DSE recommendation\n\nDSE recommends listing the attributes that influence access and identifying the trusted system permitted to supply each one. Constrain acceptable keys and values in the role trust design instead of allowing callers to assert any department or project. Review whether a tag must survive the next role assumption. Keep authorization attributes separate from free-form reporting labels, and assign responsibility for updating the mapping when the organization changes. Review conflicts between inherited and newly supplied tags before rollout. Include a deliberately conflicting attribute in the design review and write down which source should be authoritative. Have the identity and resource owners agree the expected access result before any test, rather than accepting whichever value appears in a successful session.\n\n## Verification\n\nProposed verification: assume a disposable role with an allowed attribute, a disallowed value and an unexpected transitive key. Follow the intended role chain and confirm the resulting access. Inspect both trust decisions and resource authorization rather than checking only whether a tag appears.\n\n## Official reference\n\n[AWS Documentation](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_session-tags.html). Reviewed October 20, 2026."
    },
    "json_ld": {
        "@context": "https://schema.org",
        "@graph": [
            {
                "@type": "Organization",
                "@id": "https://dsesecurity.com/#organization",
                "name": "Detection Systems & Engineering",
                "alternateName": "DSE Security",
                "url": "https://dsesecurity.com/",
                "logo": {
                    "@type": "ImageObject",
                    "url": "https://update.dsesecurity.com/assets/dse-logo-20260812.png?v=1.8.20"
                }
            },
            {
                "@type": "Organization",
                "@id": "https://update.dsesecurity.com/#editorial-team",
                "name": "DSE Security Editorial Team",
                "url": "https://update.dsesecurity.com/",
                "parentOrganization": {
                    "@id": "https://dsesecurity.com/#organization"
                }
            },
            {
                "@type": "WebSite",
                "@id": "https://update.dsesecurity.com/#website",
                "name": "DSE Updates",
                "alternateName": "DSE Security Knowledge Hub",
                "url": "https://update.dsesecurity.com/",
                "inLanguage": "en-US",
                "publisher": {
                    "@id": "https://dsesecurity.com/#organization"
                },
                "potentialAction": {
                    "@type": "SearchAction",
                    "target": {
                        "@type": "EntryPoint",
                        "urlTemplate": "https://update.dsesecurity.com/?q={search_term_string}"
                    },
                    "query-input": "required name=search_term_string"
                }
            },
            {
                "@type": "WebPage",
                "@id": "https://update.dsesecurity.com/updates/restrict-who-can-supply-aws-session-tags-used-for-authorization/",
                "url": "https://update.dsesecurity.com/updates/restrict-who-can-supply-aws-session-tags-used-for-authorization/",
                "isPartOf": {
                    "@id": "https://update.dsesecurity.com/#website"
                },
                "lastReviewed": "2026-10-20"
            },
            {
                "@type": "BreadcrumbList",
                "@id": "https://update.dsesecurity.com/updates/restrict-who-can-supply-aws-session-tags-used-for-authorization/#breadcrumbs",
                "itemListElement": [
                    {
                        "@type": "ListItem",
                        "position": 1,
                        "name": "DSE Updates",
                        "item": "https://update.dsesecurity.com/"
                    },
                    {
                        "@type": "ListItem",
                        "position": 2,
                        "name": "Cybersecurity",
                        "item": "https://update.dsesecurity.com/topic/cybersecurity/"
                    },
                    {
                        "@type": "ListItem",
                        "position": 3,
                        "name": "Restrict who can supply AWS session tags used for authorization",
                        "item": "https://update.dsesecurity.com/updates/restrict-who-can-supply-aws-session-tags-used-for-authorization/"
                    }
                ]
            },
            {
                "@type": [
                    "Article",
                    "TechArticle"
                ],
                "@id": "https://update.dsesecurity.com/updates/restrict-who-can-supply-aws-session-tags-used-for-authorization/#article",
                "identifier": "https://update.dsesecurity.com/updates/restrict-who-can-supply-aws-session-tags-used-for-authorization/",
                "url": "https://update.dsesecurity.com/updates/restrict-who-can-supply-aws-session-tags-used-for-authorization/",
                "headline": "Restrict who can supply AWS session tags used for authorization",
                "description": "Treat permission-bearing session attributes as controlled inputs.",
                "abstract": "Treat permission-bearing session attributes as controlled inputs.",
                "articleBody": "Treat permission-bearing session attributes as controlled inputs.\nSource facts\nAWS STS can pass session tags and mark selected keys as transitive through role chaining. Relevant role trust policies need sts:TagSession permission. Session tags can override matching tags, and AWS provides conditions to constrain tag keys, values and transitive keys. Tags are therefore part of the authorization design.\nSource: AWS Documentation.\nApplicability\nApply this to AWS attribute-based access workflows that rely on session tags, including federated role sessions.\nDSE recommendation\nDSE recommends listing the attributes that influence access and identifying the trusted system permitted to supply each one. Constrain acceptable keys and values in the role trust design instead of allowing callers to assert any department or project. Review whether a tag must survive the next role assumption. Keep authorization attributes separate from free-form reporting labels, and assign responsibility for updating the mapping when the organization changes. Review conflicts between inherited and newly supplied tags before rollout. Include a deliberately conflicting attribute in the design review and write down which source should be authoritative. Have the identity and resource owners agree the expected access result before any test, rather than accepting whichever value appears in a successful session.\nVerification\nProposed verification: assume a disposable role with an allowed attribute, a disallowed value and an unexpected transitive key. Follow the intended role chain and confirm the resulting access. Inspect both trust decisions and resource authorization rather than checking only whether a tag appears.\nOfficial reference\nAWS Documentation. Reviewed October 20, 2026.",
                "datePublished": "2026-10-20T18:13:32+00:00",
                "dateModified": "2026-10-20T18:34:28+00:00",
                "mainEntityOfPage": {
                    "@id": "https://update.dsesecurity.com/updates/restrict-who-can-supply-aws-session-tags-used-for-authorization/"
                },
                "inLanguage": "en-US",
                "isAccessibleForFree": true,
                "author": {
                    "@type": "Organization",
                    "name": "DSE Security Editorial Team",
                    "url": "https://update.dsesecurity.com/#editorial-team"
                },
                "publisher": {
                    "@id": "https://dsesecurity.com/#organization"
                },
                "image": {
                    "@type": "ImageObject",
                    "@id": "https://update.dsesecurity.com/updates/restrict-who-can-supply-aws-session-tags-used-for-authorization/#primaryimage",
                    "url": "https://update.dsesecurity.com/assets/editorial/cyber-defense-social-v2.jpg?v=1.8.20",
                    "contentUrl": "https://update.dsesecurity.com/assets/editorial/cyber-defense-social-v2.jpg?v=1.8.20",
                    "width": 1200,
                    "height": 630,
                    "caption": "Restrict who can supply AWS session tags used for authorization"
                },
                "articleSection": [
                    "Cybersecurity",
                    "IT"
                ],
                "keywords": [
                    "Cybersecurity",
                    "IT",
                    "Guide",
                    "Information priority"
                ],
                "genre": "Guide",
                "about": [
                    {
                        "@type": "Thing",
                        "name": "Cybersecurity",
                        "url": "https://update.dsesecurity.com/topic/cybersecurity/"
                    },
                    {
                        "@type": "Thing",
                        "name": "IT",
                        "url": "https://update.dsesecurity.com/topic/it/"
                    }
                ],
                "wordCount": 248,
                "timeRequired": "PT2M",
                "publishingPrinciples": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/",
                "usageInfo": "https://update.dsesecurity.com/usage/",
                "copyrightHolder": {
                    "@id": "https://dsesecurity.com/#organization"
                },
                "copyrightNotice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.",
                "citation": {
                    "@type": "CreativeWork",
                    "name": "AWS Documentation",
                    "url": "https://docs.aws.amazon.com/IAM/latest/UserGuide/id_session-tags.html"
                }
            }
        ]
    }
}