為了簡化開發並提高生產力，大多數的現代架構都允許自動個體化物件，並填入名稱與要繫結之類別的屬性相符的 HTTP 要求參數。自動個體化並填入物件可以加速開發，但是如果實作不慎，就可能會導致嚴重問題。已繫結類別或巢狀類別中的任何屬性將會自動繫結至 HTTP 要求參數。因此，惡意的使用者便能夠將值指派給已繫結或巢狀類別中的任何屬性，即使這些類別並未透過網頁表單或 API 約定而暴露給用戶端。

範例 1：在沒有其他組態的情況下，以下 ASP.NET MVC 控制項方法會將 HTTP 要求參數繫結至 RegisterModel 或 Details 類別中的任何屬性：

public ActionResult Register(RegisterModel model)
{
    if (ModelState.IsValid)
    {
        try
        {
            return RedirectToAction("Index", "Home");
        }
        catch (MembershipCreateUserException e)
        {
            ModelState.AddModelError("", "");
        }
    }
    return View(model);
}

其中 RegisterModel 類別定義為：

public class RegisterModel
{
    [BindRequired]
    [Display(Name = "User name")]
    public string UserName { get; set; }

    [BindRequired]
    [DataType(DataType.Password)]
    [Display(Name = "Password")]
    public string Password { get; set; }

    [DataType(DataType.Password)]
    [Display(Name = "Confirm password")]
    public string ConfirmPassword { get; set; }

    public Details Details { get; set; }

    public RegisterModel()
    {
        Details = new Details();
    }
}

而 Details 類別定義為：

public class Details
{
    public bool IsAdmin { get; set; }
    ...
}

範例 2：在 ASP.NET MVC 或 Web API 應用程式中使用 TryUpdateModel() 或 UpdateModel() 時，模型繫結器會根據預設，自動嘗試繫結所有 HTTP 要求參數：

public ViewResult Register()
{
    var model = new RegisterModel();
    TryUpdateModel<RegisterModel>(model);
    return View("detail", model);
}

範例 3：在 ASP.NET Web API 應用程式中，模型繫結器將根據預設，使用配置的 JSON 或 XML 序列化程式/還原序列化程式，自動嘗試繫結所有 HTTP 要求參數。根據預設，繫結器將嘗試繫結 HTTP 要求參數或本體中的所有可能屬性：

public class ProductsController : ApiController
{
  public string SaveProduct([FromBody] Product p)
  {
      return p.Name;
  }
  ...
}

範例 4：在 ASP.NET 網頁表單應用程式中，使用 TryUpdateModel() 或 UpdateModel() 搭配 IValueProvider 介面時，模型繫結器會自動嘗試繫結所有 HTTP 要求參數。

Employee emp = new Employee();
TryUpdateModel(emp, new System.Web.ModelBinding.FormValueProvider(ModelBindingExecutionContext)); 
if (ModelState.IsValid)
{
    db.SaveChanges();
}

而 Employee 類別定義為：

 public class Employee
    {
        public Employee()
        {
            IsAdmin = false;
            IsManager = false;
        }
        public string Name { get; set; }
        public string Email { get; set; }
        public bool IsManager { get; set; }
        public bool IsAdmin { get; set; }
    }

模型物件是以物件導向表示的資料庫實體。它們提供簡便的方法來載入、儲存、更新及刪除相關聯的資料庫實體。
Hibernate、Microsoft .NET Entity framework 及 LINQ 都是物件關係對應 (ORM) 架構的範例，可協助您建置資料庫支援的模型物件。

許多 Web 框架都提供了某種機制，用於根據對要求參數名稱與模型物件參數名稱的比對 (根據相符的公用 getter 與 setter 方法)，將要求參數繫結至要求繫結的物件，以努力減輕開發人員的工作負擔。

若應用程式使用 ORM 類別做為要求繫結的物件，則也許要求參數能修改對應模型物件中的任何欄位，以及物件屬性的任何巢狀欄位。

範例 1：Order、Customer 和 Profile 都是 Microsoft .NET 實體持續性類別。

public class Order {
	public string ordered { get; set; }
	public List<LineItem> LineItems { get; set; }
	pubilc virtual Customer Customer { get; set; }
...
}
public class Customer {
	public int CustomerId { get; set; }
	...
	public virtual Profile Profile { get; set; }
...
}
public class Profile {
	public int profileId { get; set; }
	public string username { get; set; }
	public string password { get; set; }
	...
}

OrderController 則是處理要求的 ASP.NET MVC 控制項類別：

public class OrderController : Controller{
	StoreEntities db = new StoreEntities();
...

	public String updateOrder(Order order) {
		...
		db.Orders.Add(order);
		db.SaveChanges();
	}
}

因為模型實體類別會自動繫結至要求，所以攻擊者可能利用此弱點，透過將下列要求參數新增到要求來更新另一名使用者的密碼："http://www.yourcorp.com/webApp/updateOrder?order.customer.profile.profileId=1234&order.customer.profile.password=urpowned"

幾乎每一個對軟體系統嚴重的攻擊都是從破解程式設計師的假設開始的。在攻擊後，程式設計師所建立的假設似乎是脆弱且拙劣的，但在攻擊之前，許多程式設計師會在午休結束之前為他們的假設進行辯護。

通常會發現兩個顯而易見的問題假設，分別是「這個函數呼叫不可能會出錯」以及「就算函數呼叫失敗也沒關係」。因此當程式設計師忽略函數的回傳值時，這就暗示著他們已經做了上述的假設。
範例 1： 以下程式碼在呼叫 Equals() 成員函數前，不會檢查 Item 屬性回傳的字串是否為 null，可能會造成 null 解除參照。

string itemName = request.Item(ITEM_NAME);
	if (itemName.Equals(IMPORTANT_ITEM)) {
		...
	}
	...

通常對此編碼錯誤的辯解為：

「我知道要求的值會永遠存在，因為…如果這個值不存在，程式就無法執行想要的運作方式，所以無論是我處理這個錯誤或是只要讓程式停止解除參照 null 值都沒有關係。

但是，攻擊者對於在程式中尋找意料之外的情況十分在行，特別是牽涉到異常的時候。

幾乎每一個對軟體系統嚴重的攻擊都是從破解程式設計師的假設開始的。在攻擊後，程式設計師所建立的假設似乎是脆弱且拙劣的，但在攻擊之前，許多程式設計師會在午休結束之前為他們的假設進行辯護。

通常會發現兩個顯而易見的問題假設，分別是「這個函數呼叫不可能會出錯」以及「就算函數呼叫失敗也沒關係」。因此當程式設計師忽略函數的回傳值時，這就暗示著他們已經做了上述的假設。
範例 1： 以下程式碼中，在使用由 malloc() 回傳的指標之前，並不會檢查記憶體是否已成功分配。

    buf = (char*) malloc(req_size);
    strncpy(buf, xfer, req_size);

通常對此編碼錯誤的辯解為：

「如果我的程式耗盡了所有的記憶體的話，它將必定會失敗。當程式試圖忽略一個 Null 指標時，無論是我處理這個錯誤，還是只是簡單讓程式由於程式分段錯誤而自行崩潰都沒什麼關係。」

但是這個藉口忽略了以下三個重要的因素：

- 視應用程式的類型以及大小而定，在釋放記憶體的同時，該記憶體在別處正在被其他程式函數使用，而這不會影響其他程式函數的正常執行。

- 程式無法在需要時執行正常結束。如果程式執行不可部分完成的作業，它會使系統處於不一致狀態。

- 程式設計師失去了記錄診斷資訊的機會。對 malloc() 呼叫的失敗是由於 req_size 太大，或者因為在同一時刻有太多的要求需要被處理？或者是由於建立已久的記憶體洩露所引起的？若不處理此錯誤，我們將永遠不知道答案。