String Conditions and s3:prefix

String conditions let you restrict access based on the value of a string in the request context. The most useful pairing for S3 is a string operator on the s3:prefix context key, which scopes s3:ListBucket to a folder inside a bucket.

For IP-based conditions, see Policy Conditions.

When to use string conditions

Use a string condition on s3:prefix to:

• Limit a user to listing objects under a specific folder.

• Give each user a private folder inside a shared bucket using ${aws:username}.

• Block listing of a sensitive sub-folder with an explicit Deny.

For the step-by-step how-to with copy-paste policies, see Restrict an IAM user to a folder.

Each operator takes a context key and one or more values. Wildcards are only interpreted in StringLike and StringNotLike patterns. The matcher treats the request value as a literal byte sequence: no URL decoding, no Unicode normalization, no path normalization.

Example

{
    "Version": "2012-10-17",
    "Statement": [{
        "Effect": "Allow",
        "Action": "s3:ListBucket",
        "Resource": "arn:aws:s3:::my-bucket",
        "Condition": {
            "StringLike": { "s3:prefix": "team-data/projectA/*" }
        }
    }]
}

This statement allows s3:ListBucket only when the request's --prefix parameter starts with team-data/projectA/. Every other request is denied.

Modifier suffix: ...IfExists

Append IfExists to any string operator to make the condition pass when the context key is absent:

• StringEqualsIfExists

• StringLikeIfExists

• StringNotLikeIfExists

With IfExists, a request that omits --prefix passes the condition. Without IfExists, the same request is denied because the context key is treated as missing.

"Condition": {
    "StringLikeIfExists": { "s3:prefix": "team-data/projectA/*" }
}

Set-operator prefixes: ForAllValues, ForAnyValue

Multi-valued context keys (currently rare for s3:prefix, common for future keys) are evaluated with set semantics:

• ForAllValues:StringLike - every value in the context must match at least one pattern.

• ForAnyValue:StringLike - at least one value in the context must match a pattern.

These prefixes attach to any string operator. Example:

"Condition": {
    "ForAnyValue:StringLike": {
        "s3:prefix": ["team-data/projectA/*", "team-data/projectB/*"]
    }
}

Policy variables in condition values

Variables expand inside Condition values, not only inside Resource ARNs. The supported variable is:

The resolved value is treated as a literal string. Special characters such as +, @, and . round-trip without URL encoding.

Example: per-user folder isolation

{
    "Version": "2012-10-17",
    "Statement": [{
        "Effect": "Allow",
        "Action": "s3:ListBucket",
        "Resource": "arn:aws:s3:::my-bucket",
        "Condition": {
            "StringLike": { "s3:prefix": "user-data/${aws:username}/*" }
        }
    }]
}

Each user can list only their own folder under user-data/<their-username>/.

The s3:prefix context key

s3:prefix is populated from the prefix query parameter on ListObjectsV2. The key is present when the client sends --prefix <value> with a non-empty value. The key is treated as absent when the client omits --prefix or sends --prefix "".

s3:prefix is available on s3:ListBucket actions. The context key is not populated for s3:ListBucketVersions or s3:ListMultipartUploads. A policy using StringLike on s3:prefix for those actions denies even when the request prefix matches.

Combining conditions

Multiple condition keys inside one Condition block are joined with AND. All must hold for the statement to apply.

"Condition": {
    "IpAddress":  { "aws:SourceIp": "203.0.113.0/24" },
    "StringLike": { "s3:prefix":    "user-data/${aws:username}/*" }
}

This statement requires both the source IP and the prefix to match. Either failing denies the request.

Multiple statements in one policy union with OR for Allow, and explicit Deny wins over Allow. See Restrict an IAM user to a folder for the canonical Allow + Deny pattern that blocks a sensitive sub-folder.

Operators not yet evaluated

The following operators parse without an error but evaluate as always-false, so policies using them deny every request:

• Numeric operators: NumericEquals, NumericNotEquals, NumericLessThan, NumericLessThanEquals, NumericGreaterThan, NumericGreaterThanEquals

• Date operators: DateEquals, DateNotEquals, DateLessThan, DateLessThanEquals, DateGreaterThan, DateGreaterThanEquals

• Boolean operator: Bool

• ARN operators: ArnEquals, ArnLike

• Binary operator: BinaryEquals

If you need behavior that one of these would normally provide, rewrite the policy using IpAddress or one of the supported string operators.