This weakness occurs when software assumes a value cannot be changed—such as a user ID, file path, or security token—but fails to enforce that assumption. An…
This weakness occurs when software assumes a value cannot be changed—such as a user ID, file path, or security token—but fails to enforce that assumption. An attacker who can modify that "immutable" value can bypass security checks that depend on it. The result is often privilege escalation, unauthorized access, or data tampering.
Developers often treat certain data as read-only by convention rather than by design. A user ID might be stored in a session variable, a configuration file path in a constant, or a permission flag in a cookie—with the implicit assumption that the application (or the user) won't change it. However, if that data is stored in a location an attacker can reach—a client-side cookie, a URL parameter, a hidden form field, or a mutable object passed between functions—the attacker can modify it. If the application then makes a security decision based on that modified value without re-validating it, the security check fails.
The core issue is the gap between what the developer *assumes* is immutable and what is actually protected from modification. This is especially dangerous in multi-tier or distributed systems where data crosses trust boundaries.
An attacker exploiting this weakness can escalate privileges (e.g., changing a user ID to an admin ID), access another user's data, bypass payment or licensing checks, or modify audit logs. In some cases, it can lead to complete account takeover or unauthorized administrative actions. The impact depends on which value is modified and how it is used in downstream security decisions.
# Assume user_id is passed in a URL parameter and stored in session
@app.route('/user/profile')
def view_profile():
user_id = request.args.get('user_id') # Attacker can change this
session['user_id'] = user_id # Stored without validation
# Later, a security decision relies on this value
user_data = db.query("SELECT * FROM users WHERE id = ?", session['user_id'])
return render_template('profile.html', user=user_data)Why it's vulnerable:
The user_id comes directly from user input and is stored in the session without validation. An attacker can modify the URL parameter to view another user's profile, and the application trusts the session value without re-checking ownership.
# Establish the user ID from authentication, not user input
@app.route('/user/profile')
def view_profile():
# Retrieve user_id from the authenticated session/token, not from request parameters
user_id = session.get('authenticated_user_id')
if not user_id:
return redirect('/login')
# Verify the user owns the requested resource before returning it
user_data = db.query("SELECT * FROM users WHERE id = ?", user_id)
if not user_data:
return abort(404)
return render_template('profile.html', user=user_data)<?php
// User ID is passed in a hidden form field and trusted directly
if ($_POST['action'] === 'delete_post') {
$user_id = $_POST['user_id']; // Attacker can modify this
$post_id = $_POST['post_id'];
// Security decision based on unvalidated user_id
$result = $wpdb->query(
$wpdb->prepare("DELETE FROM posts WHERE id = %d AND author_id = %d",
$post_id, $user_id)
);
echo "Post deleted.";
}
?>Why it's vulnerable:
The user_id is taken directly from POST data without verification. An attacker can modify the hidden field to delete posts belonging to another user.
<?php
// Retrieve the authenticated user ID from the session, not from user input
if ($_POST['action'] === 'delete_post') {
$user_id = get_current_user_id(); // From authentication, not POST
$post_id = intval($_POST['post_id']);
// Verify the post belongs to the authenticated user before deletion
$post = $wpdb->get_row(
$wpdb->prepare("SELECT author_id FROM posts WHERE id = %d", $post_id)
);
if (!$post || $post->author_id != $user_id) {
wp_die('Unauthorized');
}
$wpdb->query(
$wpdb->prepare("DELETE FROM posts WHERE id = %d", $post_id)
);
echo "Post deleted.";
}
?>- Users report being able to view or modify other users' data by changing URL parameters or form fields. - Audit logs show actions attributed to the wrong user, or timestamps that don't match user activity. - Privilege escalation reports where a low-privilege user gained admin access without credentials.
